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Preface 



IFM 2000, the second in a series of international conferences on Integrated For- 
mal Methods, was held at the 18th-century chateau of Schloss Dagstuhl, Saar- 
land, Germany, from the 1st to the 3rd of November 2000. 

The conference programme consisted of invited talks from Sir Tony Hoare 
FRS and Wolfram Schulte, along with 22 papers selected from 58 submissions. 

Applying formal methods may involve the modelling of different aspects of 
a system that are expressed through different paradigms. This motivates us 
to research the combination of different viewpoints of a system, either by the 
creation of hybrid notations, by extending existing notations, by translating 
between notations, or by incorporating a wider perspective with the innovative 
use of an existing notation. 

The integration of formal methods promises great benefits to systems mo- 
delling and software development. Regardless of the approach taken, however, 
significant issues can arise in areas such as semantic integration, the tractabi- 
lity of our notations, the integration of tool support, the integration of proof 
systems, consistency, and completeness. Issues arise equally in our conceptuali- 
sation of systems at different levels of abstraction and the development of these 
conceptualisations through the process of refinement. 

The stated theme of IFM’99 was the integration of state-based and behaviou- 
ral formalisms. For IFM 2000 this was widened, and the submitted papers have 
been grouped in five technical sessions, covering the linking and extending of 
notations, methodology, the foundation of one formalism in another, semantics, 
and aspects of verification and validation. 

We hope that these proceedings will be of benefit both to the conference 
participants and to the wider community of workers in the field. The production 
of these proceedings would not have been possible without the invaluable help 
of the programme committee and external referees, and of all the contributors 
who submitted papers to the conference. 
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Assertions 



Tony Hoare 

Senior Researcher 
Microsoft Research Ltd. 

1 Guildhall St., Cambridge, CB2 3NH 
thoareOmicrosof t . com 

An assertion is a Boolean formula written in the text of a program, which 
the programmer asserts will always be true when that part of the program is 
executed. It specifies an internal interface between that part of the program 
that comes before it and all that follows it. In the software industry today, 
assertions are conditionally compiled in test runs of a program, and help in 
the detection and diagnosis of errors. Alan Turing first proposed assertions as 
a means of checking a large routine. They were rediscovered independently by 
Naur as generalised snapshots, and by Floyd, who used them to assign meanings 
to programs. Floyd suggested that if the internal assertions were strong enough, 
they would constitute a formal proof of the correctness of a complete program. 
In this lecture, I will summarise the subsequent development of the idea, and 
describe some of its practical impact. 

In the early seventies, I developed an axiomatic approach for proofs of pro- 
grams that use all the main constructions of a high-level programming langu- 
age - iterations, local variables, procedures and parameters, recursion, and even 
jumps. Following Dijkstra, I always took a top-down view of the task of software 
construction, with assertions formulated as part of program specification, and 
with proofs conducted as part of program design. I hoped that this research 
would help to reduce the high costs of programming error, and the high risks of 
using computers in critical applications. But the real attraction for me was that 
the axioms underlying program proofs would provide an objective and scientific 
test of the quality of programming language design: a language described by a 
small collection of obvious rules, easily applied, would be better than one that 
required many rules with complex side-conditions. In collaboration with Wirth, 
we tried out the idea on the Pascal language; and later it inspired the design of 
Euclid by a team in Xerox PARC. 

In scaling proof methods from small sequential algorithms to large software 
systems, it was necessary to extend the power of the assertion language. The 
Z specification language was developed by Abrial on the basis of Zermelo’s set 
theory, which Frankel showed to be essentially adequate for expression of all 
concepts known to mathematics. It should therefore be adequate to express all 
the abstractions useful to computing, and prove the correctness of their repre- 
sentations. Dijkstra dealt with non-determinism, by imagining the choice to be 
exercised maliciously by a demon. Jones and his fellow designers of VDM in- 
cluded initial as well as final values of program variables. All these ideas were 
successfully tested by IBM in specifying the internal interfaces of a large system, 
CICS. 
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The next challenge was to extend the technology to concurrent programs. 
Milner suggested that their meaning could be specified by the collection of tests 
which they passed. Following Popper’s criterion of falsifiability, Roscoe and Broo- 
kes concentrated on failures of a test, and constructed a non-deterministic model 
of concurrency, following the paradigm of Communicating Sequential Processes. 
This was applied industrially by the British start-up microchip Company Inmos 
in the design of the Occam programming language, and the architecture of the 
transputer which implemented it. Finally, Hehner showed how Roscoe’s results 
could be coded directly in the language of assertions, so that any kind of pro- 
gram, concurrent as well as sequential, could be interpreted as the strongest 
assertion that describes all its possible behaviours. 

This insight has inspired all my subsequent research. With the aid of He 
Jifeng, it has been applied to wider varieties of programming paradigm and 
language, including hardware and software, parallel and sequential, declarative 
and procedural. Ignoring radical differences in syntax, and abstracting from im- 
plementation technology, very similar definitions and mathematical laws apply 
in many different paradigms; perhaps Computing Science has achieved a level 
of maturity to undertake the challenge that drives the progress of many other 
sciences, namely unification of theories of programming. 



State-Based Extension of CASE* 



Hubert Baumeister^ and Alexandre Zamulin^ 



^ Institute of Computer Science, University of Munich 
baumeist@informatik.uni-muenchen.de 
^ Instiute of Informatics Systems 
Siberian Division of Russian Academy of Sciences 
zamOiis .nsk. su 



Abstract. A state-based extension of the algebraic specification langu- 
age CASL is presented. It permits the specification of the static part of 
a complex dynamic system by means of CASL and the dynamic part 
by means of the facilities described in the paper. The dynamic system 
is defined as possessing a number of states and a number of operations 
(procedures) for transforming one state into another. Each state pos- 
sesses one and the same static part specified by CASL and a varying 
part specified by additional tools. The varying part includes dynamic 
sorts/functions/predicates and dependent functions/predicates. The de- 
pendent functions/predicates are specihed by formulae using the names 
of the dynamic functions/predicates so that each time one of the last ones 
is updated the corresponding former ones are also updated. The updates 
of the dynamic entities are produced by procedures which are specified 
by means of preconditions, postconditions, and dynamic equations. 



1 Introduction 

The Common Framework Initiative (CoFI) [18] is an open collaborative effort 
to design a common framework for algebraic specifications. The rational behind 
CoFI is that the lack of such a framework greatly hinders the dissemination and 
application of research results in algebraic specification. The aim is to base the 
common framework as much as possible on a critical selection of features that 
have already been explored in various contexts. The common framework will 
provide a family of languages centered around a single, reasonably expressive 
common specification language called CASL [17]. Some of these languages will 
be extensions of CASL, e.g. oriented to particular programming paradigms, while 
others will be sub-languages of CASL, e.g. executable. 

In this paper we define SB-CASL, a state-based extension of CASL [17] which 
is based on algebraic specifications and the concept of implicit state a la Z, B, 
or VDM, also known as the state-as-algebra approach. In contrast to Z, VDM, 
and B, this approach does not constrain a specifier by a fixed number of basic 
types and type constructors used for the representation of application data, and 
gives a formal semantics for all notions used in the method. SB-CASL brings 

* This research has been partially supported by ESPRIT working group 29432 
(CoFI WG) and the Russian Foundation for Basic Research under Grant 98-01- 
00682 
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together ideas from Typed Gurevich Machines of Zamulin [19], based on the 
original work of Gurevich [13,14], Algebraic Specifications with Implicit State 
of Dauchy and Gaudel, first presented in [8] and further developed in [15,9], D- 
oids by Astesiano and Zucca [2,20,21], and the work of Baumeister [3,4,5]. The 
formalism serves for the specification of dynamic systems possessing a state and 
a number of operations for accessing and updating the state. 

The novelty of SB-GASL is that it combines the operational style for the 
specification of state transformations with the declarative style in a practical 
specification language. In the operational style one defines how one state is trans- 
formed into another; in contrast, in the declarative style only the properties that 
the successor state has to posses are specified and not how the state is construc- 
ted. Up to now either only the operational style was used, like in ASM’s and the 
Implicit State approach, or only the declarative style was used as in the approach 
by Baumeister. A notable exception is the approach by Zucca [21] which also 
allows both styles of specifications; however her intention was not to provide a 
specification language. 

The paper is organized as follows. The GASL institution is briefly described 
in Sec. 2. States and state updates are defined in Sec. 3. Dynamic systems are 
introduced in Sec. 4. Transition terms, serving for the construction of dynamic 
formulae, are described in Sec. 5 and dynamic formulae in Sec. 6. The structure 
of a dynamic system specification and supporting examples are given in Sec. 7. 
Some related work is discussed in Sec. 8, and in Sec. 9 some conclusions are 
drawn. 



2 The CASL Institution 

A basic specification in GASL consists of a many-sorted signature S together 
with a set of sentences. The (loose) semantics of a basic specification is the class 
of those models in Mod(i7) which satisfy all the specified sentences. For reasons 
of simplicity we restrict ourselves to the many-sorted part of GASL and leave out 
the order-sorted part. However, all the subsequent constructions in this paper 
can also be performed in the presence of a subsorting relationship. 

A many-sorted signature E = (S, TF , PF , P) consists of: 

— a set S of sorts; 

— sets TFw,s, PFw,s, of total function symbols, respectively partial function 
symbols, such that TF^^s H PFy„^s = 0, for each function profile {w, s) con- 
sisting of a sequence of argument sorts w G S* and a result sort s G S 
(constants are treated as functions with no arguments); 

— sets Pw of predicate symbols, for each predicate profile consisting of a sequence 
of argument sorts w G S*. 

Here and in the sequel a function (predicate) symbol is a name accompanied 
with a profile. Names may be overloaded, occurring in more than one of the 
above sets. 

In this paper we write a total function symbol as / : Si, . . . , — >■ s and a 

partial function symbol as / : si, . . . , — >■? s. When the list of argument values 

is empty, we write s and 7s, respectively. 
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For a many-sorted signature E = (S', TF, PF,P) a many-sorted model A G 
Mod(i7) is a many-sorted first-order structure consisting of a many-sorted par- 
tial algebra: 

— a non-empty carrier set | A|s for each sort s € S (let \ A\^ denote the cartesian 

product X • • • X when w = s\ . . . s„), 

— a partial function f^ from \A\^ to |A|s for each function symbol / G TFy^^s 
or / € PFyj^s, the function being required to be total in the former case, 

— together with a predicate p^ C \A\yj for each predicate symbol p G Pw 

Many-sorted terms on a signature E = (S, TF, PF, P) and a set of sorted, 
non-overloaded variables X are built from: 

— universally quantified variables from X, introduced by 

var V \\ , . . . , Vifc . Si , . . . , Vji \ , . . . , Vnm • 

— applications of function symbols in TF U PF to argument terms of appro- 
priate sorts. 

For a many-sorted signature E = (S,TF,PF,P), the set of Fi-sentences 
consists of sort-generation constraints and the usual closed many-sorted first- 
order logic formulae, built from atomic formulae using quantification (over sorted 
variables) and logical connectives. The atomic formulae are: 

— applications of predicate symbols p G P to argument terms of appropriate 
sorts; 

— assertions about the definedness of terms, written deft; 

— existential and strong equations between terms of the same sort, written 
ti = t 2 and ti = t 2 , respectively. 

The satisfaction of a sentence in a structure A is determined as usual by the 
holding of its atomic formulae w.r.t. assignments of (defined) values to all the 
variables that occur in them. The value of a term w.r.t. a variable assignment may 
be undefined due to the application of a partial function during the evaluation 
of the term, or because some arguments of a function application are undefined. 
The satisfaction of sentences, however, is 2-valued. 

The application of a predicate symbol p to a sequence of argument terms 
holds in A iff the values of all the terms are defined and give a tuple belonging 
to A definedness assertion concerning a term holds iff the value of the term is 
defined. An existential equation holds iff the values of both terms are defined and 
identical, whereas a strong equation holds also when the values of both terms 
are undefined. A sort-generation constraint (S", F") is satisfied in a F7-model A 
if the carriers of the sorts in S" are generated by the function symbols in F'. 

3 States and State Updates 

The signature of a system defined by SB-CASL includes a part 

E stat — {,Sstati TFstat, P Fstat 1 Pstat) 
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which defines some data types (sorts and operations) using the standard CASL 
facilities. These data types are used for the specification of system’s states and 
the description of possible state updates. A Astorstructure is called a static 
structure in the sequel. 

The system’s states are defined by dynamic sorts, dynamic functions, and 
dynamic predicates. The names and profiles of these sorts/functions/predicates, 
^dyn = {Sdyn,TFdy„,PFdyn,Pdyn), form a signature extension of the static sig- 
nature Estat- 

We require that each dynamic function f : w ^ s where s is a dynamic sort 
from Sdyn or w contains a dynamic sort from Sdyn is in PFdyn- The reason is that 
a function having a dynamic sort in its profile may become partial if elements 
are added or removed from this sort. 

In the rest of this paper we denote by Edyn = {S' ,TF' , PF' , P') the union 

of E with /\dyn- 

Example 1. The first example is a specification of an identifier table. The identi- 
fier table stores some data for each identifier definition. It can be block-structured 
according to block nesting. Typical functions are creating an empty identifier ta- 
ble, inserting identifier data in the current block, checking whether an identifier 
is defined in the current block, checking whether an identifier is defined in the 
program, fetching identifier data, and deleting all identifier definitions of the 
current block. 

The following specification defines the state of the identifier table. The static 
signature is given by the union of the signatures of NAT, NAME, and DEFDATA; 
and id_table and cur Jevel are dynamic functions: 

System ID .TABLE 

use NAT, NAME, DEFDATA ** The specifications used 

dynamic 

func id.table: Name, Pos — >7 Defdata; 

func curdevel: Pos; ** the current level of block nesting 



Example 2. The second example is taken from one of the latest work of Zucca 
[21]. The procedures (dynamic operations in her paper), whose ’’intended inter- 
pretation” is described at the model level in that paper, will be formally specified 
here. 

System CIRCLES 

use REAL, COLOUR ** The spec. COLOUR has only two constants 
** ’’green” and ’’red” of sort ’’Colour” 

dynamic 

sort Circle; 

func X, Y: Circle — Real; 
func radius: Circle — >■ Real; 
func col: Circle — > Colour; 

A dynamic sort/function/predicate can be different in different states. 
Definition 1. A Edyn~state is a Edyn~ structure where Edyn = EstatO Adyn- 
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The restriction of any EdynState A to Sstat, A\s^^t, is a static structure 
called the base of A. Several Sdyn~sta,tes can have the same base. Following [15], 
we denote the set of all EdynStaAes with the same base B by stateB{Edyn) and 
mean by a i7^„-state a i7dj^„-state with the static structure B. Thus, the carrier 
of any static sort s € S^tat in a EdynState A is the same as the carrier of s in 
B, that is |A|s = \B\g. 

3.1 Update-Sets 

One state can be transformed into another by a state update which is either a 
function update or a predicate update or a sort update. 

Definition 2. Let B he a static structure over Egtat- A function update in a 
E^y^-state A is a triple (/, a,a) where f^s is a dynamic function (constant) 
symbol in Adyn, w = si . . .Sn, d = <ai, ...,an> € l^jm (d is the empty tuple <> 
when n is equal to zero), and a is either an element of |A|s or the symbol T. A 
function update (/, d,T) is valid only if f is the symbol of a partial function. 

A function update a = (/, a,a) serves for the transformation of a A£^„-state A 
into a new A^^-state Aa in the following way: 

— for any G TF' U PF' different from /; 

— /^“(a) = a if a is not T, /^“(d) becomes udefined otherwise; 

— f^°‘{d') = f^{d') for any tuple d' = <a[, . . . , a[j> different from d; 

— = p"^ for any S P'; 

— \Aa\s = |A|s for any s G S' . 

Following Gurevich [13], we say that Aa. is obtained by firing the update a on 
A. Roughly speaking, firing a function update either inserts an element in the 
definition domain of a dynamic function or modifies the value of such a function 
at one point in its domain or removes an element from the definition domain. 

Definition 3. Let B he a static structure over E^tat- A predicate update in 
a E^y^-state A is a either a triple (+,p,d) or a triple (— ,p, d) where Pw is a 
predicate symbol in Adyn, w = si . . . Sn, and d = <a \, ..., a„> G \A\n,. 

A predicate update fS = {f,p, d) serves for the transformation of a if^„-state 
A into a new A^^-state Afd in the following way: 

— p"^^(d) holds if e is ”+” and p^^(d) does not hold if f is 

— p^^{d') iff p^{d') for any tuple d' = <a'i, . . . , a^> different from d; 

— for any Ou, G Pdvn different from p; 

— for any Us G TF' U PF'; and 

— \Ap\s = \A\s for any s G S'. 



Definition 4. Let s be the name of a dynamic sort. A sort-update S in A is 
either a triple (+,s,id) where id is an element such that id ^ |A|s or a triple 
{—,s,id) where id is an element such that id G ]A|s. 
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A sort update S = (+, s, id) transforms a A^^^-state A into a new I7^„-state 
AS in the following way: 

— |A(5|s = \A\s U {id}, 

— |A(5js' = |A|s/ for any s' G S' different from s, 

— = r for any G TF' U PF', and 

— for any G P' . 

A sort update S = {—,s, id) transforms a A^j^-state A into a new A^„-state 
AS in the following way: 

— for any function : |A|si x ... x |A|s„ -)> if |A|s,, i = l,...,n+ 1, 

is a dynamic sort associated with the sort name s and id G |A|^., then 
if there is a maplet <ai,...,a„ i— >• a„+i> G such that ai = id, then 
jAS = fA\^ {<«!, .. a„ H> a„+i>}; otherwise; 

— for any predicate p^ : |A|si x ... x |A|s„, if |A|s-, i = l,...,n, is a dynamic 
sort associated with the sort name s and id G |A|s., then if there is a tuple 
<ai, ..., a„> G p^ such that Oi = id, then p^^ = p^\ {<oi, ..., a„>}; p^^ = 
p"^ otherwise; 

— |A(5|s = As \ {id} and |Ai5|s' = |A|s' for any s' different from s. 

Thus, the sort update i5 = (— ,s,a) contracts the set of elements of a cer- 
tain sort and deletes the corresponding entries from the graphs of all dynamic 
functions and predicates using and/or producing the element indicated. 

Note that it is possible to create algebras with empty carrier sets using sort 
updates. For example, if A is an algebra with |A|s = {a} and S = (— ,s,a), 
then |Ai5|s = {}• This is in contradiction with the requirement that within the 
CAST institution carrier sets are non-empty. To solve this problem we introduce 
the institution SB-CASL which is the same as the CAST institution, but allows 
their models to have empty carrier sets. Note that the introduction of empty 
carriers does not pose any problems with the satisfaction relation in case of 
partial logic (cf. [7]), and that any many-sorted model of the CAST institution 
is also a model of the SB-CASL institution. 

Definition 5. Let F he a set of function/predicate/sort updates. The set F is 
inconsistent if it contains either 

— two contradictory function updates of the following kind: a\ = (/, a, a) and 
a-i = (/, a, o'), where a ^ a' (two contradictory function updates define the 
function differently at the same point), or 

— two contradictory predicate updates of the following kind: /3i = (+,p,d) and 
(32 = {—,p,d) (two contradictory predicate updates define the predicate dif- 
ferently at the same tuple of arguments), or 

— two sort updates of the following kind: = (-|-,s,td) and S 2 = {—,s,id) 

(two contradictory sort updates insert in the sort and delete from the sort 
the same element), or 

— either an a = (/, <ai, ..., a„>, a„+i) for an f^ : |A|^^ x ... x \ A\s„ -A \ A\s„^^ 
or a (3 = {^,p, <ai, ..., a„>) for a p^ : | A|sj x ... x \A\s„, and S = (-, s, id) 
such that s is Si for some i = 1, ...,n + 1 and id = ai (a sort element is 
removed while a function/predicate is forced to use it); 

the update set is consistent otherwise. 
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A consistent update-set F applied to a A^^^-state A transforms A into a new 
F^y^-sta,te A' by simultaneous firing all a € A, all /3 G F, and all 6 £ F. If F 
is inconsistent, the new state in not defined. If F is empty, A' is the same as A. 
Following [16], we denote the application of A to a state A by AF. The set of 
all consistent sets of updates in statesiF) is denoted by updatesiF dyn) in the 
sequel. 

Definition 6. Let Fi and F2 be two consistent update-sets in a F^^^-state A, 
= (/, (oi,... ,a„),a), 02 = (/, (oi,... ,a„),a'), /?i = (^i,p, (ai, . . . ,a„}), 
02 = (oi, . . . ,an)), i5i = {-\-,s,id), and 62 = {—,s,id), where a a' 

and both ^1 and ^2 <if’& either ”+” or such that ^1 is different from ^2- 
The sequential union of Fi and F2, denoted by Fi ; F2, is defined as follows: 
u £ Fi •, F2 iff u £ Fi or u £ F2, except the following cases: 

— if ai £ Fi and 02 £ F2, then 02 G A ; A and a\^F\\ A/ 

— if 01 £ A o-n-d 02 £ A; then A S A ; A and A ^ A j A/ 

— if Si = (— , s, a) £ A) then for any a = (5, (oi, . . . , a„), a„+i) G A> where 

: \A\s^ X...X |A|s„ \A\s„^^, and for any 0 = (^,p, <ai,... ,a„>) G A, 

where p^ : | x ... x | A|s„ .• if s is Si, i = 1 , ..., n 1, and Oi = id, then 
a ^ A ; A and /3 ^ A ; A; and if S2 = (+, s, a) £ A Aen both i5i ^ A ; A 
and A ^ A ; A- 

Thus, in a sequential union of update sets, each next update of a function/pre- 
dicate at a certain point waives each preceding update of this function/predicate 
at the same point. If there are sequential creations of elements of the same sort, 
the set of elements of this sort will be expanded accordingly. If there is a deletion 
of an element, the corresponding sort will be contracted accordingly and all 
function/predicate updates involving this element will be ignored. Note that if 
an element is first created and then deleted, then the resulting update set will 
contain no trace of this element. 

3.2 Dependent Functions and Predicates 

A function update of the form a = (/, a, a) applied to a A^j^„-state A does not 
change any other function g, only / at point d is changed. Consider now the 
following partial function find: Name — >■? Defdata fetching data for a name 
in ID .TABLE. Clearly the result of find depends on the state of ID .TABLE; 
thus find has to be a dynamic function. Further, find depends on the dynamic 
function id-table because, starting from the current block level, find looks for 
the definition of an identifier at each block level. Thus we expect that whenever 
id-table is changed so is find. However, the semantics of update-sets and dynamic 
functions does not provide us with such an automatism. 

To still allow such functions as find, we introduce dependent functions and 
dependent predicates as a second set of state components. They form a signature 
extension — (0, T Fy^^p, P F,igp, Pdep^ of F dyn where TFdep P Fdep — 0- Note 
that the set of sort names of Adep is empty; we don’t allow for dependent sorts. 
As with dynamic functions, we require that each dependent function / : ic — >• s 
where s is a dynamic sort from Sdyn or w contains a dynamic sort from Sdyn 
is in PFdep- For example, the following dependent functions/predicates can be 
defined in the system ID .TABLE: 
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depend 

pred defined-Current: Name; ** checks whether an id is defined in the current 
block 

pred is_defined: Name; ** checks whether an id is defined in the table 
func find: Name — >7 Defdata; ** fetches data from the table 

Definition 7. A Sf^^-state is a E dep- structure with the static structure B where 

E dep — E dyn U ^dep ■ 

Thus, dependent functions/predicates extend a E^y^-state to a I7£.p-state. The 
set of all T'^.p-states with the same static structure B is denoted by state b{E dep)- 

4 Dynamic Systems 

A state update modifies the dynamic and dependent functions/predicates. Pos- 
sible state updates are specified by procedures declared in the fourth part of the 
system’s signature, Aproc, which consists of sets TPy^^PP-ui of total procedure 
symbols, respectively partial procedure symbols, such that TP-^i fi PPw = 0i for 
each procedure profile w consisting of a sequence of argument sorts from Edep- 

Example 3. For example, the following procedures can be defined in the system 
ID_TABLE: 

proc 

initialize; ** construction of an empty identifier table 

insert_entry: ? Name, Defdata; ** insertion of a new entry in the identifier table 
newdevel; ** creation of a new level of nesting in the identifier table 
deletedevel ?; ** deletion of the last block in the identifier table 



Example f. The following procedures can be declared in the system CIRCLES: 

proc 

start; ** create one circle with default attributes 
move: Circle, Real, Real; ** change the coordinates of a circle 
moveAll: Real, Real; ** change the coordinates of all circles 
resize: Circle, Real; ** change the radius of a circle 
changeCol: Circle; ** change the colour of a circle 

copy: circle ** create a new circle with the attributes of the argument circle 
delCreen; ** delete all green circles 



Definition 8. The signature DE = (Egtat, Adyn, Adep, Aproc) of a dynamic sy- 
stem consists of 

— a static signature Estat,' 

— a signature extension A dyn of Egtat by symbols of dynamic sorts, functions, 
and predicates such that the profiles of total functions do not contain a dy- 
namic sort; 

— a signature extension Adep of Egtat^Adyn by symbols of dependent functions 
and predicates, but without dependent sorts; and 
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— two families of sets Aproc = {TP,PP) of total and partial procedure symbols. 

Definition 9. A dynamic system, DS{B), of signature DS consists of 

— a set of states \DS{B) \ C statesiB dep) > called the carrier of the system; 

— a partial surjective function : statesiBldyn) — >■ \DS{B)\ such 

that if A) is defined, then map^^^^\A)\s,iy„ = A for each A G 

state ]d ( B dyn) ! 

— for each procedure symbol p : si, . . . , s„, a (partial) map associating 

an update set P € updatesiBdyn) with a state A of DS{B) and a tuple 
<ai , . . . , a„> where Oi G ,i=l,... ,n. 

Given a dynamic system DS{B), we call a i7rfep-structure A a state of DS{B) if 
A G \DS{B)\. 

We write [A, a) for the application of a procedure to a pair 

consisting of a state A and a tuple a where A G \DS{B)\ and d = <ai, 

For a procedure p, we say that p is a constant procedure if the result of 
a) does not depend on A. This kind of procedure can be used for the 
initialization of a dynamic system. 

5 Transition Terms 

State updates are specified by means of special transition terms. The interpre- 
tation of a transition term TT in a dynamic system DS{B) at a state A w.r.t. a 
variable assignment a \ X ^ \A\ produces an update set P or is undefined. The 
corresponding state A' after firing the update set can be obtained by 

T = map^^^^\{A\^,jP) 

for which we will simply write, in abuse of notation, A' = AP . 

5.1 Basic Transition Terms 

Basic transition terms are update instructions, procedure call, sort contraction 
instruction, and the skip instruction. 

Update instructions. Let / be the name of a dynamic function with the 
profile si, . . . , Sn ^ s, g the name of a partial dynamic function with the profile 
si, . . . ,Sn^s,p the name of a dynamic predicate with the profile si, . . . , s„, X 
a set of sorted variables, t^ a term of sort Si over signature Bdep with variables 
X for i = 1, ..., n. Then 



f{ti,...,tn) := t, 

g{ti, ...,tn) := undef 
p{ti, ...,t„) := true, 
p{ti, ...,tn) ■.= false 



are transition terms called update instructions. 
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Interpretation. If A is a state of DS{B), a a variable assignment, t and U^i = 
1, . . . ,n, are defined terms in A under a, then 

:= = {(/, <tf . . . , 

lg{ti,...,tn) ■= undeJl^’'" = {(g, <tf . ,tn’'^>,-L)} 

|p(ti, := true]^’'" = {(+,p, <tf . An’'">)}, 

lp{ti,...,tn) ■■= falsej^’'" = {(-,p,<tf ,tn’'">)}^ 

If at least one of t, i = 1, . . . , n, is not defined in A under a, then the inter- 
pretation of the above transition terms is undefined. 

Example 5. Let a; be a variable of sort Nat and / be a dynamic function from 
Nat to Nat. The execution of the transition term f{x) := f{x) + 1 under the 
variable assignment cr = {a; i— >■ a} transforms a state A into a state A' so that 
(a) = f^{a) + 1 and (n) = f^{n) for all n ^ a. 

If c is a partial dynamic constant, a transition term c := undef will make c 
undefined in the new state. 



Procedure call. If p : si, ..., is a procedure symbol and ti , ..., are terms of 
sorts si, ..., s„ over Edep with variables from X, then p{ti, ..., tn) is a transition 
term called a proeedure call. 

Interpretation. Let DS{B) be a dynamic system of signature DE, A a state in 
\DS{B)\, and a a variable assignment. The interpretation of a procedure call is 
defined as follows: 

[p(ti, ..., ..., t^’''>) 

if each tf’‘^, i = 1, ..., n, is defined and is defined for the state A and the 

tuple <tf’'^,...,tn’'^>\ Ip(ti, is undefined otherwise. 

Sort contraction. If t is a term of a dynamic sort s, then drop t is a transition 
term called a sort contraction. 

Interpretation: [drop = 6 where 6 = (— 



Skip. The transition term skip causes no state update, i.e. Iskip]"^’"^ = 0. 

5.2 Transition Term Constructors 

Complex transition terms are constructed recursively from basic transition terms 
by means of several term constructors, e.g., sequence constructor, set constructor, 
condition constructor, guarded update, loop constructor, import constructor, and 
massive update. 
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Sequence constructor. If TTi,TT2, . . . ,TTn are transition terms, then 

seq TTi , TT2 , . . . , TT„ end 

is a transition term called a sequence of transition terms. 

Interpretation. Let A be a state, A = Ai = AFi, I2 = 

A2 = AiF2, ...,F„ = Then 

|seq TTi, TT2, ...,TT„ endj^’^ = F, 

where F = Fi ; F2 ; F^ and each is defined. 

Thus, to execute a sequence of transition terms starting with a state A, it is 
sufficient to create the sequential union of their update sets and use it for the 
transformation of A (which is equivalent to the sequential execution of the terms 
one after another). 

Set constructor. If TTi, . . . ,TT„ are transition terms, then 

set TTi , ... , TTn end 
is a transition term called a set of transition terms. 

Interpretation. Let A be a state and Fi = |TTi]^’°', ... ,F^ = Then 

|set TTi, . . . , TTn end]^’'^ = A U . . . U 

if each is defined and A U ... U A is consistent; the semantics is not 

defined otherwise. 

In other words, to execute a set of transition terms, execute all of them in 
parallel and unite the results if they are consistent. 

Condition constructor. If /c is a natural number, 50; ■■■, 9 k are formulae, and 
TTo,...,TTfe are transition terms, then the following expression is a transition 
term called a conditional transition term: 

if go then TTq 
elseif gi then TT\ 



elseif gk then TA 
endif 

If gk is the formula true, then the last elseif clause can be replaced with 
’’else TTk \ We also write if g then TT for if g then TT else skip endif. 

Interpretation. Let A be a state, a a variable assignment, and TT a conditional 
transition term, then 

if gi holds in A w.r.t. cr, but every gj with j < i fails in A w.r.t. a. |TT]^’°’ = 0 
if every gi fails in A w.r.t. a. 
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Loop constructors. The condition constructor together with the sequence 
constructor gives us a possibility to define some loop constructors. If TT is a 
transition term and g is a formula, then while g do TT and do TT until g are 
transition terms. 

Interpretation. 

[while g do = |if g then seq TT, while g do TT end]^’"^; 

|do TT until = |seq TT, if -•g then do TT until 5 ]'^’'^. 

Import constructor. If x is a variable, s is a dynamic sort name and TT is a 
transition term, then import x : s in TT is a transition term called an import 
term. 

Interpretation. Let A' = AS, 5 = (+, s, a) for some a ^ As, and a' = cr0{x a} 
where ”0” is the overriding union, i.e. (cr0cr")(x) = cr"{x) if x is in the domain 
of a" and (cr 0 cr''){x) = a{x) otherwise, then 

[import X : s in = {5}; 

Massive update. Let x be a variable of sort s and TT a transition term. A 
massive update 

forall X : s . TT 

permits the specification of a parallel update of one or more sorts/functions/ 
predicates at several points. 

Interpretation. Let A be a state such that |A|s is not empty, let cr and a' = 
{x} — |A|s be variable assignment, and let cr" = ct 0 a' . Then 

— if [TT]'^’'^ is defined and T = } is consistent, then 

[forall X : s . TT}^''^ = T; 

— [forall X : s . is not defined otherwise. 

If |A|^ = 0, then [forall x : s . TTJ^’"^ = 0. That is, the massive update over 
the empty sort produces nothing. 

Example 6. Let / be a dynamic function from Nat to Nat. A transition term 
forall X : Nat . /(x) := /(x) 0 1 
interpreted in a state A yields the update-set 

{(/, n, f^{n) 0 1) I n e |A|jvat} 
if f^{n) is defined for all n. 

Example 7. The execution of the update set produced by the transition term 

forall X : s . drop x 

at the current state A will remove all elements from |A|s and will make empty 
all functions and predicates using s in their profiles. 
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6 Dynamic Formulae 

For the specification of dynamic systems we introduce dynamic formulae which 
can be dynamic equations, precondition formulae, or postcondition formulae. A 
dynamic equation serves for the specification of a behaviour of a procedure in 
terms of a transition rule. A precondition formula allows us to define the domain 
of a procedure. Finally, a postcondition formula is used to specify the behaviour 
of a procedure similar to VDM or Z. 

6.1 Dynamic Equations 

A dynamic equation is of the form TT\ = TT 2 where TT\ and TT 2 are transition 
terms over variables from X. A dynamic system DS{B) satisfies a dynamic 
equation if for all states A of DS{B) and variable assignments tr : A — >■ |A|: 

A|rTil"^’‘" = AlTTz]^’'" and AlTTi/al^’'" G \DS{B)\. 

The most common use of dynamic equations is in the form: 

p{xi, ... ,Xn) =TT 

where TT does not contain a direct or indirect call of p. This defines the semantics 
of p in a dynamic system to be a function mapping a state A and a tuple 
<Oi, . . . ,a„> to the update set given by the interpretation of TT w.r.t. A and 
the variable assignment mapping each Xi to a^. 

Example 8. For a simple example consider a dynamic constant counter : Int 
and procedures Inc and Dec. The procedure Inc can be defined by the following 
dynamic equation: 



Inc = counter := counter + 1. 

Similarly, Dec can be defined using the dynamic equation 

Dec = counter := counter — 1. 

However, dynamic equations need not follow the pattern p{x\, . . . ,Xn) = TT. 
For example, an alternative way to define Dec from the previous example is by 
the following dynamic equation: 

seq Dec, Inc end = skip. 

This means that whenever a Dec procedure is followed by an Inc procedure, the 
state of the system should not change. 

6.2 Precondition Formulae 

Let p be an element of PPsi,... ,s„, i-e. a partial procedure symbol, and fi, . . . ,tn 
are terms over S^ep with variables from X . A precondition formula of the form 
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pre ,tn) ■ can be used to state under which conditions a partial 

procedure p is guaranteed to be defined. 

A dynamic system DS{B) satisfies a precondition formula iff the value of 
pDS(B)^^^ . . . , is defined in exactly those states A and for 

those variable assignments cr for which p holds. 

The following precondition formula 

pre insert-entry {id, d) : -'defined-current{id) 

states that the partial procedure insert-entry declared in Ex. 3 for the dynamic 
system I DATABLE must be defined only in those states A and only for those 
arguments id for which the interpretation of defined-current is false. 

6.3 Postcondition Formulae 

Dynamic equations of the form p{x\, . . . ,Xn) = TT can be used to specify 
dynamic systems in an operational style similiar to Gurevich’s ASMs. 

However, sometimes it is convenient to use a declarative style similar to the 
one used by the specification languages Z and VDM. In the declarative style, the 
values of a dynamic/dependent component before and after the execution of a 
procedure are related by a first-order formula. Usually this formula only defines 
the relationship between the values and does not provide an algorithm how to 
change the value. For example, the Dec operation of Ex. 8 could be defined by 
a postcondition formula 

post Dec : counter = counteif + 1 

where counter refers to the value of counter in the state before executing the 
Dec operation, and counted refers to the value of counter after executing Dec. 
Note that this formula does not prescribe how the value of counter is computed 
after performing the Dec operation. In contrast, a dynamic equation of the form 

Dec = counter := counter — I 

defines an update-set used for changing the value of counter. 

To be more precise, let A be a state of a dynamic system DS{B) containing 
the dynamic constant counter and a procedure Dec. Then the interpretation of 
Dec in DS{B) yields the update-set = D which applied to a state 

A yields the state AD. Then AD has the following property: the interpretation 
of counter in A has to be the same as the interpretation of counter in AD plus 1: 

counter^'^^ = counter^^'^^ + 1 . 

The general syntax of a postcondition formula is: 

post p{ti,... ,t„) : (p 

where p is a (partial) procedure, ti,... ,tn are terms over and p is a 

formula over the signature E which is constructed as follows. First consider 
the case where there are no dynamic sorts, then the sorts of E are the static 
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sorts of Sstat- The operation symbols (total or partial) of S are those defined 
in the static signature plus two copies of the dynamic and dependent function 
symbols: one copy denoting the function before the execution of a procedure and 
one copy, decorated by a prime (/), denoting the function after the execution of 
a procedure. Similar for the predicate symbols of S. 

To define whether ip is satisfied by a state A and an update-set F, we con- 
struct from A and AF a if-model A^ as follows. The interpretation of a static 
signature component, i.e. a sort, operation, or predicate symbol from Sgtat, is the 
same as the interpretation of that component in A. Note that this is the same as 
the interpretation of that symbol in AF and B, because = B = AF\s,t^f 

The interpretation of a dynamic or dependent signature component in A^ is 
either the interpretation of that component in A, or, if this is a component with 
a prime in S, the interpretation of the corresponding unprimed component in 
AF. Then a state A and an update-set F satisfy a formula ip iff A^ |= ip. 

In the case of dynamic sorts the construction is similar. That is, E contains 
the static sorts plus two copies of the dynamic sorts, one copy decorated with a 
prime. However, the profile of a primed dynamic or dependent function/predicate 
in E having a dynamic sort in its profile changes. Each dynamic sort in the profile 
has to be replaced by its primed version. Note that the profiles of unprimed 
function/predicate symbols remain the same. 

As an example consider the dynamic system CIRCLES, which has a dynamic 
sort Circle and a dynamic function X : Circle — >■? Real (among others). Now the 
signature E contains two sorts Circle and Circle' and two function symbols 
X : Circle — ?►? Real and X' : Circle' — >■? Real. Note that in the profile of X' the 
dynamic sort Circle is also decorated with a prime. 

There is still another problem with dynamic sorts. Consider the following 
specification of the move operation in the dynamic system CIRCLES: 

post move{c, x,y) \ X' {c) = X{c) + x /\ Y' (c) = Y{c) + y 

Note that the formula above is not well-formed w.r.t. E because X' is a function 
from Circle' to Real while c is of sort Circle., and similar for Y' and c. The solution 
is to introduce in E a partial function tmg \ s ^ s' called a tracking map for 
each dynamic sort s. The notion of tracking map was first introduced with d-oids 
(cf. [1,2,20,21]). In our example we use the function tmcircie ■ Circle — >■? Circle' 
and write 

post move{c,x,y) : X' {tmcirde{.c)) = X{c) + x A Y' (tmarcie{c)) = Y{c) + y 

In the sequel we leave the application of the tracking map implicit whenever 
possible. If t[r] is a term with a subterm r and r is required to be of dynamic sort 
s', then we allow r to be of dynamic sort s and understand this as an abbreviation 
for t\tms{r)]. This allows us to write the above postcondition formula as: 

post move{c, x, y) : X'{c) = X{c) + x AY' (c) = Y (c) -I- y 

For the interpretation of the tracking maps in A^ we have to define the 
tracking map associated with a dynamic sort and an update-set. This tracking 
map is undefined for elements that are removed and is the identity otherwise. 
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_L if (5 = (— , s,a) G r 
a else 



= I 

The definition of satisfaction remains the same, i.e. A and F satisfy (p if 
h (p. The formal definition of S and A^ is given in App. A. 

7 Specification of Dynamic Systems 

Definition 10. A dynamic system specification 

DSS = {SPEC, Adyn, {Adep, Ax), {A procj AXp’roc)) 
has four levels: 

— The first level is a CAST specification SPEC with semantics {Estat, M). 
SPEC defines the data types used in the system. 

— The second level defines those aspects of the system’s state which are likely 
to change. It includes a signature extension, A^yn, which declares some dy- 
namic s orts /functions /predicates . 

— The third level defines some dependent functions/predicates and indicates 
state invariants. It does not introduce new sorts and uses the names of dy- 
namic functions/predicates from Adyn, the names of dependent function/pre- 
dicates from Adep, und the operations of Egtat- The formulae in Ax restrict 
the set of possible states of a dynamic system satisfying DSS. 

— The fourth level, {Ap^oc, Axproc)> defines some procedures. Axp^oc is a set 
of dynamic formulae. 

A dynamic system specification DSS defines a dynamic signature 
DE — {Egtat: Adyni Adep, '^proc); 

and a dynamic system DS{B) over signature DE satisfies a dynamic specifiction 
DSS iff 

— B is a, model of SPEC, 

— \DS{B)\ is the set {A \ Ag statesiEdep) f\ A\= Ax}, 

— DS{B) satisfies each dynamic formula in Axproc- 



Example 9. 

** specification of the ’’ID^TABLE” system 
System ID .TABLE 

use NAT, NAME, DEFDATA ** The specifications used 

dynamic 

id.table: Name, Pos — >7 Defdata; 

curTevel: Pos; - the current level of block nesting 

depend 

pred defined.current, is.defined: Name; 

pred locaLdefined: Name, Pos; 

func locaLfind: Name, Pos — >7 Defdata; 
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func find: Name — >7 Defdata; 
var id: Name, k: Pos 

• defined-current(id) def id_table(id, curJevel)); 

• local_defined(id, 0) false; 

• local_defined(id, k) def id_table(id, k)V local_defined(id, k-1); 

• is_defined(id) local_defined(id, curJevel); 

• locaLfind(id, k) = idJable(id, k) when def id_table(id, k) 

else locaLfind (id, k-1)}; 

• find(id) = local_find(id, curJevel) if is-defined(id); 

proc 

initialize; ** construction of an empty identifier table 
insert_entry: ? Name, Defdata; 
newJevel; 
delete Jevel?; 

var id: Name, k: Pos, d: Defdata 

• pre delete Jevel: curJevel > 1; 

• pre insert_entry(id, d): -■ defined_current(id); 

• initialize = set curJevel := 1, 

forall id: Name, x: Pos. idJable(id, x) := undef end; 

• post insert _entry (id, d): idJable’(id, curJevel) = d; 

• post newJevel: curJevel’ = cur Jevel -I- 1; 

• delete Jevel = set curJevel := curJevel — 1, 

forall id: Name. idJable(id, curJevel) := undef end; 



Example 10. 

System CIRCLES 

use REAL, COLOUR ** The spec. COLOUR has only two constants 
** ’’green” and ’’red” of sort ’’Colour” 

dynamic 
sort Circle; 

func X, Y: Circle — >1 Real; 
func radius: Circle — >7 Real; 
func col: Circle — >7 Colour 

proc 

start; ** creation of one circle with default attributes 
move: Circle, Real, Real; ** change the coordinates of a circle 
moveAll: Real, Real; ** change the coordinates of all circles 
resize: Circle, Real; ** change the radius of a circle 
changeCol: Circle; ** change the colour of a circle 

copy: circle ** create a new circle with the attributes of the argument circle 
delCreen; ** delete all green circles 
var X, y, r: Real, dr: Circle 

• start = seq forall c: Circle, drop c, 
import c: Circle in 

set X(c) := 0, Y(c) := 0, radius(c) := 1, col(c) := green end 



end; 
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• post move(cir, x, y): X’(cir) = X’(cir) + x A Y’(cir) = Y(cir) + y; 

• moveAll(x, y) = forall c: Circle. 

set X(c) := X(c) + x, Y(c) := Y(c) + y end; 

• post resize(cir, r): radius’(cir) = r; 

• changeCol(cir) = if colour(cir) = green then colour(cir) := red 

else colour (dr) := green endif; 

• copy(cir) = import c: Circle in set X(c) := X(cir), 

Y(c) := Y(cir), radius(c) := radius(cir), col(c) := col(cir) end; 

• delGreen = forall c: Circle, if colour(c) = green then drop c; 
end 



8 Related Work 

As mentioned in the introduction, this extension of CASL is based on several 
works using the concept of implicit state. Currently none of them offers the full 
set of tools needed for the specification of a broad range of dynamic systems. 
Therefore the natural combination of the facilities offered by these works and 
their adaptation to the CASL institution has been one of our main goals. 

We have liked very much the concept of update set introduced by Gure- 
vich in [13] for the explanation of state transitions. It was used later by him in 
[14] for giving denotational semantics of transition rules of Abstract State Ma- 
chines (ASMs). We also give the semantics of our transition terms in terms of 
update sets. However, ASMs are based on total universal algebras treating predi- 
cates as Boolean functions. Since our states are partial many-sorted structures, 
we have extended a-updates of ASMs with [3- and (5-updates representing, res- 
pectively, the updates over predicates and sorts. Our notion of transition term 
is an extension and generalization of the ASM notion of transition rule. The 
amendments are the procedure call, the drop rule allowing a sort to shrink, 
the sequence constructor and based on it the loop constructors (see also [6] for 
another proposition of sequence and loop constructors) . ASMs do not have such 
features as dependent functions and procedures, nor is the notion of dynamic 
system defined for them. 

Dependent functions and procedures are borrowed from [8,15] through inter- 
mediate steps of [19,9]. However, their semantics is different. In [19,9] dependent 
functions are not part of the state; they belong to the dynamic system, and this 
caused some problems with the use of their names in terms. In [8,15] dependent 
functions are part of the state with a very complex semantics of their redefinition 
in different states. The introduction of the function map has allowed us to treat 
dependent functions as part of the state with very simple semantics of their re- 
definition. The semantics of modifiers (analogue of our procedures) and update 
expressions (analogue of our transition terms) is given in [8,15] operationally 
(there is no notion of update set in this approach), while we have done it denot- 
ationally. We have also provided the means for working with partial structures 
(only total many-sorted algebras are used in [8,15]). 

The notion of dynamic system, as it is defined in our paper, stems from the 
notion of d-oid introduced in [1,2] and further developed in [20,21]. A d-oid is a 
set of instance structures (e.g., algebras), a set of dynamic functions resembling 
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our dependent functions and procedures and a tracking map indicating relati- 
onships between instance structures. The approach deals with models and does 
not address the issue of d-oid specification. Therefore, we had to borrow and 
adapt for our purpose a specification technique of another source. 

Another approach are “Transition Categories” presented in [10,11]. Here the 
algebra of data types is equipped with sorts called reference sorts in addition 
to ordinary sorts, and the state extends this algebra by partial functions called 
contents functions for each reference sort which map elements of reference sorts 
to their contents. State transformations are defined by conditional parallel assig- 
nment redefining the contents functions. Though based on different semantical 
foundations, Grofie-Rhode’s approach appears as a special class of dynamic sy- 
stem defined in this paper where the static part contains the reference sorts and 
the only components of the dynamic part are the contents functions. Then the 
effect of conditional parallel assignment can be achieved using dynamic equati- 
ons. 

In a later work [12], Grofie-Rhode defines Algebra Rewrite Systems. A rewrite 
rule r is of the form Pi i — >■ Pj. where Pi = (Xi,Ei) and Pr = (Xr,Er) are 
presentations consisting of sets of generators Xi and Xr and sets of equations Ei 
and Er, respectively. A rule is applied to a partial algebra A by first removing 
the elements of Xi from the carrier sets of A together with the equalities in 
El, and then adding the elements in X^ and the equalities in E^. This allows 
the modelling of update instructions /(ti) := ^2 by first undefining a function 
entry and then adding a new function entry by a rule ({a: : s}, {/(ti) = x}) i — > 
{{x : s},{/(ti) = t 2 \). Deletion of an element of sort s is modeled by a rule 
({a: : s}, 0) ^ (0, 0), and creation of an element by a rule (0, 0) i — ({a; : s}, 0) 
However, the approach by GroBe-Rhode is restricted to partial algebras and thus 
cannot be used in the context of GASL, which is order-sorted and in addition to 
partial function contains total functions and predicates. Further, the application 
of rewrite rules and also the interaction between axioms defining the static part 
with rewrite rules may yield unexpected results, like the identification of elements 
in the result state. 

While all the above approaches favour an operational style of writing spe- 
cifications, with the exception of Zucca [21], that is, they specify how a state 
is transformed into another state, the approach by Baumeister [3,4,5] uses a 
declarative approach, defining how the states before and after the execution of 
a state transformation are related. This allows writing specifications which are 
similar to those written in specification languages like Z or VDM. Baumeister’s 
approach does not require states to be modeled as algebras; states can be struc- 
tures from any suitable institution. From this approach we have used the idea 
how to interpret postcondition formulae. 

9 Conclusion 

In this paper we have defined an extension of GASL for the specification of state- 
based software systems intended to be part of the common framework defined 
by the Gommon Framework Initiative. It permits the specification of the static 
part of a complex dynamic system by means of GASL and the dynamic part by 
means of the facilities described in the paper. This is one level of integration of 
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two different specification paradigms. The specification of the dynamic part can 
also be done either by means of transition rules or by means of postconditions 
(where it is appropriate). This provides the second level of integration. Moreover, 
the use of update sets for describing the semantics of both transition rules and 
postconditions has permitted us to define the semantics in a simple way and 
easily solve the well-known frame problem. 

The next step in the development of the described specification technique 
is the introduction of structuring facilities permitting the specifications to be 
united, localized, parameterized, etc. 
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A Postcondition Formnlae 

In this section we give a formal definition of E, , and postcondition formulae. 
Let 

Adyn — {,Sdyn-! PEdyn-, Pdyn) 

be a signature extension w.r.t. Estat = i.Sstat,TFstat,PFstat,Pstat), 

^dep — (0, TFdep, PFdep, Pdep) 
be a signature extension w.r.t. Estat U Adyn, then 

A = {S, TF, PF, P) = {SdymTFdyn U TFdep, PFdyn U PFdep, Pdyn U Pdep) 
is a signature extension w.r.t. Estat- We define E = {S,TF,PF,P) as follows: 
S = Sstat U Sdyn U {s | S C S dyn\ 

TF = {f : w ^ so \ f : w ^ So € {TFstat UTF)} U 

{f' ■ Si, . . . ,Sn ^ So \ f : Si, . . . , Sn ^ So € TF, 

Si = s'i if Si € Sdyn, Si = Si else, 0 < i < n} 

PF = {/ : tc — t So I / : tc — >• So G (P Fgtat U P F)} U 

{f' : si, . . . , s„ — t So I / : si, . . . , s„ — > So C PF, 

Si = s'i if Si G Sdyn, Si = Si else, 0 < i < n} U 
{tiris : s -)> s' I s G Sdyn} 



P = {p:w\p-.wG {Pstat U P)} U 

{p' : si,... ,s„ |p: si,... ,s„ G P, 

Si — Si if Si G Sdyn, Si — Si else, 0 ^ ^ Tl} 
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Definition 11. A postcondition formula is a formula of the form 

post p{ti, ... An) -^P 

where p \ s\, ..., Sn is a procedure symbol, si, . . . ,Sn are sorts in Sstat U Sdyn, 
ti, . . . An are terms over variables X of sorts si, . . . , and p is a formula 
over S with variables X . 

Given a state A in a dynamic system DS{B) and an update-set F, we define 
a if-structure by: 

l^^ls = l^ls if S G Sstat U Sdyn 
\A^\s' = \Ar\s As' GS\{S States dyn) 

for all sort symbols in S, 

fA^ = /^ if / e TFstat u TF 

f,A^ = jAr g rjTp ^ ^ pp^ 

for all total function symbols in PF, 

fA^ = /^ if / g PFstat U PF 
= tmp^ if / = tms 

f'A^ = f^^ if /' € P~F \ {PFstat U PF U {tms \ S € Sdyn}) 

for all partial function symbols in PF, and 

p^"' =p^ if p G Pstat U P 
p'^^ =pAr if/gp\(p^,„,up) 

for all predicate symbols in P. 

Note that one can write f'^ = f^^ and p'^ = p^^ , though different sort 
symbols are used in the profiles of / and f {p and p'), since the carrier-set of 
each s' in A^ is the same as the carrier set of the corresponding s in AF . 

A dynamic system DS{B) satisfies a postcondition formula 

post p{ti, ... ,tn) ■ (p 

iff for any state A and variable assignment a : X ^ A: ii the update-set 



exists, then 
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Abstract. Duration Calculus (DC) is an interval-based real-time logic, 
which can be used in capturing and eliciting users’ real-time require- 
ments. The Timed RAISE Specification Language (TRSL) is an exten- 
sion of the RAISE Specification Language with real-time features. This 
paper links DC and TRSL together in a method for real-time develop- 
ments. An operational semantics with behavior is specified for TRSL. It is 
defined what its means for a TRSL process to satisfy a DC requirement, 
and a method for verifying whether the satisfaction relation holds or 
not is provided. Our contribution also demonstrates a general approach 
for linking state-based real-time logics together with event-based, timed 
process algebra languages. 

Keywords: Formal methods, RAISE, Duration Calculus, integration of 
specification formalisms. 

1 Introduction 

Duration Calculus (DC) [12] is an interval-based real-time logic, which captu- 
res and elicits users’ real-time requirements in the form of constraints on the 
durations of states of the system, i.e. at a high level of abstraction. However, 
as a state-based logic, it lacks the ability to specify sequential programs and 
communicating concurrent processes at a concrete level. 

The Timed RAISE Specification Language (TRSL) [11] has this ability. 
TRSL is a recent real-time extension of the RAISE Specification Language (RSL) 
[9] which together with its associated method [10] and tools has shown to be very 
useful in the industrial development of software systems. However, TRSL lacks 
the ability of DC to specify timing properties at a high level of abstraction. 

Therefore, a promising approach for the development of real-time systems 
could be to use DC for high-level specifications of real-time requirements and 
TRSL for specifying real-time implementations in the form of communicating 
concurrent processes. To be more precise the main idea for a development method 
for real-time systems is as follows (see figure 1): 

1. The RAISE method [10] is used for stepwise developing a specification of 
the untimed properties of the system, starting with an abstract, property- 
oriented RSL specification and ending with a concrete, implementation- 
oriented RSL specification. 



W. Grieskamp, T. Santen, and B. Stoddart (Eds.): IFM 2000, LNCS 1945, pp. 25—44, 2000. 
(c) Springer- Verlag Berlin Heidelberg 2000 
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RAISE Method 



DC method 




Fig. 1. A development method for real-time systems 



2. In parallel with the RSL development of the untimed system, a DC requi- 
rement specification of the real-time properties of that system is developed. 
State variables in the DC specification are variables defined (at least) in the 
last RSL specification. 

3. Timing information is added to the RSL specification achieving a TRSL 
specification of a real-time implementation. 

This method rises two questions: when is the TRSL specification a correct deve- 
lopment of the RSL specification, and when does it satisfy the DC requirements. 
The first question has been addressed in [2], while the goal of this paper is to 
address the second question. 

First, in section 2 we give a brief summary of the DC variant (DC with Super- 
Dense Chop) that we have used, and in section 3 we introduce an operational 
semantics with behavior for TRSL. Then, in section 4, we use the operational 
semantics with behavior to define a satisfaction relation between TRSL and 
DC, and in section 5 we present an associated verification method. In section 6 
we illustrate our method on a case study, and finally, in section 7, we state 
conclusions and topics for future work. Appendices A and B contain the rules of 
the operational semantics and proof rules of the verification method. 

2 Duration Calculus with Super-Dense Chop 

The classical Duration Calculus (DC) [12] is an interval temporal logic, which 
can be used to specify constraints on the durations of states, but not to specify 
super-dense computations, i.e. events that are instantaneous and may happen 
simultaneously. Hence, classical DC can’t be used to describe TRSL events like 
input, output and assignments that according to the TRSL time model are assu- 
med to be instantaneous and may happen simultaneously. However, there exists 
variants of DC that can be used for this purpose, e.g. Duration Calculus with 
Super-dense Chop [13] and Duration Calculus of Weakly Monotonic Time [7]. 
We have chosen to use the first of these (but could equally well have chosen 
the second one) . Duration Calculus with Super-dense Chop provides a new chop 
modality called super-dense chop and left and right neighborhood properties 
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\S' and /'/S', where S' is a state. The idea is to express instantaneous events as 
neighborhood properties and combine these sequentially using the super-dense 
chop modality which chops a time point in the grand time space into a non-point 
interval in a fine time space. For instance, the behavior of x : = x + 1 can be 
described as 3v ■ ’\{x = v)/\ /'{x = n -I- 1). 

Below we give a short survey of the syntactical categories of states, terms and 
formulas. They are all constructed from a given set 5V of typed state variables. 
The detailed semantics and axioms and theorems can be found in [13]. 

States: The set State of 5V-states is constructed from the set of state va- 
riables iSV using lifted versions of operators like = and -I-. For instance, if x 
and y are state variables of type Real then x = \ and x = y + 1 are states. 
State variables of a type T denote T-valued functions of time. States denote 
Boolean- valued functions of time. 

Terms: The set Term of 5V-terms is constructed from the set of 5V-states 
and a given set of constants Var according to the following grammar, where 
S € State, V G Var, and r G Term: 
r ::= v \ fS jr-|-r|r — rjr-r 

A term denotes a real- valued interval function. For instance, the term fS denotes 
the duration of S on the interval of consideration. 

Formulas: The set Formula of 5V-formulas is constructed from the set of 
iSV-states and the set of 5V-terms according to the following grammar, where 
S G State, r G Term, and 4> G Formula: 

(f> ::= r = r|r>r| \S' | /S' | -i(/) Ocj) 

Formulas denote Boolean-valued interval functions. For instance, the formula 
/S is true for a given interval, if there is a left neighborhood of the interval in 
which S is true, and □</> is true, if 4> is true for all subintervals. 

The following abbreviations are frequently used: 

i = fl (length of interval) 

I" ] = (^ = 0) (is a point interval) 

[S] = (^ > 0) A (fS = £) (S holds essentially) 

[S] * = I" ] V [S] (is a point or S holds essentially) 

\S = £ = 0 A /S (S holds in left neighborhood of point) 

/S = £ = 0 A /S (S holds in right neighborhood of point) 

3 An Operational Semantics with Behavior for TRSL 

An operational semantics [11] in the style of Plotkin [8] has been given for a core 
of TRSL. In order to define a satisfaction relation between TRSL specifications 
and DC formulas, below we suggest an extension of the original operational 
semantics. 



3.1 TRSL Core Syntax 

A core TRSL specification consists of a set U of declarations of program varia- 
bles, channels and values (functions), and a set A of axioms defining the values. 
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An example of a TRSL specification can be found in section 6. The syntax for 
core TRSL if-expressions used in the axioms is: 

E ::= true | false | r | T | () | skip | stop | chaos | id | x | 

A id : r • E I E E I let id = E in E | if E then E else E | 

X := E I while EdoE|EnE|E[]E|E||E|E|[E|E;E| 
wait E I let t = c?x in E | let t = c!E in E 

where a; is a variable name from Af, c a channel name from A7, t and id value 
names, r a real and T a time duration (i.e. positive real). The three last con- 
structs are the real-time constructs of TRSL. A wait statement wait E, where 
E denotes a time duration T, causes the time to elapse T time units. An input 
expression let t = c7x in E offers to input from the channel c. If this leads to 
a communication on c, the value input from c will be stored in the variable x, t 
will be bound to a time value representing the time elapsed between input being 
ready and the communication taking place, and E will be executed in the scope 
of t. The meaning of output expressions are defined similarly. The remaining 
constructs are described in [9]. Here we just give a few remarks. () is equivalent 
to skip. There are two concurrency operators: the parallel operator || and the 
interlocking operator jj-, where the latter differs from the former by not allo- 
wing its arguments to communicate with external processes, but forcing them 
to communicate with each other or deadlock if that is not possible and none of 
them can terminate. We assume that the components E\ and E 2 of concurrent 
expressions Ei || E 2 and Ei -)} E 2 do not access the same variables. 

In addition to the above syntax, we introduce the following shorthands: c\E 
is short for let t = clE in skip, c7x is short for let t = c7x in skip and c? is 
short for c7x, when x has type Unit. 

3.2 Definitions and Notation 

Here, we introduce some definitions and notation, which will be used in the 
operational semantics. 

Stores A A7-store s is a map from variables in E to values. 

Environments An environment p is a finite map from identifiers (of formal 
function parameters) to values (actual parameters). 

Events There are three kinds of H-events: Visible events (input events: c7v and 
output events: dv, where c is a channel in A7), time measurable events (e(d), 
d > 0) and silent events (e). In the semantics, “O” denotes any event; 
“A” denotes any visible or silent event; a denotes any visible event and d its 
complement event (i.e. c7v = dv and dv = c7v). 

Configurations The operational semantics is based on the evolution of con- 
figurations. A basic V-configuration is a pair < E,s >, where E is a, E- 
expression and s a V-store. Following the approach of [4,1], in the evolution 
of configurations, it is sometimes necessary to distribute the store to its sub 
expressions so that they can evolve separately. Hence, in addition to basic 
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configurations, we need a more advanced notion of configurations which are 
built from basic configurations in a similar way as composite TRSL expres- 
sions are built from basic TRSL expressions. For instance, if and ai are 
(basic) configurations then ai|~|a 2 is a configuration. The detailed mathe- 
matical definition can be found in [11]. 

Behaviors A E -behavior is a DC 17^-formula, where consists of the follo- 
wing DC state variables: 

— For each channel c in E, DC state variables c? and c!, which record when 
a process is willing to receive an input and send an output, respectively, 
on channel c. 

— For each program variable a: in A, a DC state variable x, which records 
the value of a; as a function of time. 

The purpose of a E -behavior is to record the history about the evolution of 
the observables (the state variables in E"^) of a TRSL A-process. 

In the operational rules, |"s] is an abbreviation for |"a;i = A ... A 
where s is a store equal to [xii— . . . , a;„i— \s, /^s, ’\s, and jB's are 
similar abbreviations. 

In the sequents and side conditions of the operational rules we use a number 
of auxiliary functions the meaning of which is described below. 
var(E) denotes the set of variables occuring in expression E. s\set, where set is 
a set of names, denotes the store obtained from store s by removing the names 
in set from the domain of s. Sortd{a) denotes the set of ports (channel names 
tagged with a ‘?’ or ‘!’ symbol) that corresponds to the next possible visible 
(input or output) events that a can initially evolve with within the next d units 
of time. The detailed mathematical definition of Sortd(a) can be found in [11]. 
SORTd denotes the set of ports that the environment can initially evolve with 
within the next d units of time. 

3.3 Operational Rules 

The operational rules define a labeled transition relation between configurations 
with behaviors. The basic form of the transition relation is: 

p \~ a with <j) ^ 01 with cj>' 

where p is an environment, a and a' are A-configurations, (j) and (f)' are E- 
behaviors, and e is a A-event. The transition expresses that the first step of 
execution of a when the event e happens will lead to a new configuration a' 
with a new behavior 4>' . The new behavior (history) (p' is an extension of the 
old behavior (history) cj) with the history of what could be observed during the 
event e. Other possible forms of the transition relation include: 

p \~ Oi with (f) [1 /? with (j)" t Oi with (p' D with (j)'" 

p \~ ex with (p II ^ II P with p" t CX with (p' II ^ II P with (p" 

The collection of operational rules can be found in appendix A. Here we just 
show one of the rules (without premises): 
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p h< let t = clx in E’, s > with 4, 

< E[0/t], S f [x I ^ x] > with tp • A 

It states that if a process described by an input expression let t = c?x in E in 
the context of a store s inputs a value v on channel c then this will lead to the 
new process described by the expression E[0/t] in an updated store in which x 
is bound to v. Furthermore, the new behavior will be an extension of the old 
one with a DC formula expressing that the time interval of the input event is of 
length 0 and in the left neighborhood of this interval the variables are bound to 
values as described by the old store s and in the right neighborhood the variables 
are bound to values as described by the new store s f [x !->■ x] (i.e. the value of 
X is changed to v, while all other variables are stable). 

3.4 Validation of the Operational Rules 

The original operational rules without behaviors describe (implicitly) possible 
interpretations of a E-store (cf. [11]). We have validated that the behaviors 
(DC formulas) added to the original operational rules describe these intended 
interpretations. For instance, for any conclusion of the form p \- a with 0 
Of' with 0' 1 behavior </>' must be equivalent to 4> • (p" for some </>" such 

that (p” conforms with the event e and the states s and s' of the pre and post 
configurations a and a' . This means for instance that p" must describe an inter- 
val for which (1) the length fits with e (i.e. if e is instantaneous then </)"=>£ = 0, 
and if e = e{d) then p" ^ i = d), (2) the left and right neighborhoods are s 
and s' (i.e. p" \s A j^s'), and (3) the state is stable if the event is time 
measurable (i.e. if e = e{d) then s = s' and p" => [s]). 

4 Satisfaction Relation 

In order to define the satisfaction relation, we first define the notion of a behavior 
of a TRSL expression as a finite prefix of one of its possible behavior histories 
that can be derived by repeated use of the operational rules: 

Definition 4.1 A DC formula bh is called a behavior of a TRSL E-expression 
E wrt. an initial E-store sq, iff there exists a configuration a, such that^ 

[ ] E, Sq with [ ] ( ^) ^ with hh 

Moreover, if a is of the form < v, s >, where is a computational value (i.e. a 
value literal or a lambda expression), bh is called a terminated behavior. 



Definition 4.2 A TRSL E-expression E satisfies a DC E"^ -formula p, (written 
E sati; p), iff for any initial E-store, Sq, for any behavior bh of E wrt. Sq, there 
exists a DC formula tl such that bh • tl is also a behavior of E wrt. Sq and 
bh •tl ^ p. And when bh is a terminated behavior ot E, tl = |" ] . 



^ Below, (A)* denotes the transitive closure of the transition relation. 
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5 Verification Method 

It is not always practical directly to use Definition 4.2 to prove whether a TRSL 
expression satisfies a DC requirement or not. The reason is that some TRSL 
expressions have many (sometimes even infinitely many) behaviors. This section 
gives our solution to cope with this problem. 

5.1 Common Histories 

Our main idea is to use a common history formula (or characteristic formula) 
of a TRSL expression, instead of its behaviors to prove whether the expression 
satisfies a DC formula. A common history formula of a TRSL expression is a DC 
formula which is an abstraction of all the possible behaviors of the expression. 
It expresses what is common to all its behaviors. 

Definition 5.1 A DC formula is called a common S-history (formula) of a 
TRSL A-expression E, iff for any initial A-store, Sq, for every behavior formula 
tf of E wrt. Sq, there exists a DC formula 9, such that (p • 9 is also a behavior 
wrt. So, and \=dc <p • 9 ^ if . 

Notation: If i/) is a common history of a A-expression A, we write Hx;{E) 9 ip. 
We drop the subscript A, when it is obvious from the context. 

We can now use the following theorem to prove that an expression satisfies 
a DC requirement: 

Theorem 5.2 E satx’ 4>, if there exists a common A-history formula ip of A, 
such that \=dc Ip ^ (p- 

The next problem is how we can derive a common history formula of a TRSL 
expression. Below, we will give some examples and in next subsection we intro- 
duce a proof system. 



Assignments. In a context where only one variable x has been declared, the 
behavior of the TRSL expression x \= x + 1 depends on the value of x before the 
assignment, i.e. on the initial store. Abstracting from the initial store, a common 
history of this expression is 

3v ■ \(x = v) A y'(x = V + 1) 

A common history of a; := 2 reduces to /'(x = 2) 

Wait. In a context where only one variable x has been declared, a common 
history of wait 5 is 

i = 5 A •(|"a; = i;] A \{x = v) A ^ {x = v)) 
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Sequence 1. In a context where only one variable x has been declared, a 
common history oi x := 2; wait 5 is 

/'{x = 2) • {i = 5 A = A \{x = v) A ^ (x = v))) 

which according to the rules for DC with super dense chop can be reduced to 

£ = 5 A \x = 2'\ A ^ (x = 2) 

A common history of an expression of the form ...]x := 2; wait 5; ... is of the 
form 



... • £ = 5 A \x = 2'\ • ... 

Input. The behaviors of clx wrt. an initial store [x i— >• t>o], include the following 
major forms: 

1. \ (a; = i>o) A {x = v) 

corresponding to the case where the environment is willing immediately to 
output V on channel c 

2. [a; = 'Col A £ = d A \{x = Vq) A ^ {x = Wq) 

corresponding to the case where the environment is not willing to output on 
c for d time units 

3. [a; = 'Col ^ [c?l A £ = d A \{x = vq) A ^ {x = v) 

corresponding to the case where the environment is willing after d time units 
to output the value c on c 

A common history which generalizes all these forms is: 

|"c?l* A 3co,c • ([a: = Col* A = '^o) A ^(x = v)) 

Sequence 2 (input before Consider the expression x := l;c?;x := 

2; wait 5; ... and assume that x is the only considered variable. 

For the cases where the environment is willing to output on c, we can gene- 
ralize its possible behaviors as: [a; = 1 A c?l* • (£ = 5 A \x = 2\) • . . . . For the 

cases where the environment is not willing to output on c, we can generalize its 

possible behaviors as: [a: = 1 A c? A ^(a; = 1)1*. Hence, all kinds of behaviors 
can be generalized by the following common history: 

([a: = 1 A c?l* • (f = 5 A [a: = 2) ) • ...) V [a; = 1 A c? A ^(a;=l)l* 

Concurrency. In order to find a common history of the concurrent expression 
wait 5; clx j} c!3, we first consider common histories of the sequential compo- 
nents: 

Ff(wait 5; clx) 3 

(f = 5 A 3co ■ ([a: = cqI A \{x = vq) A {x = cq))) • 

[c?l* A 3 cq, c • ( [a: = CqI* A \{x = Cg) A ^{x = c)) 

and 

FT(c!3) 9 [c!l* 
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(Note that the common history of c!3 is found in a context with no variables.) 

TRSL has a maximal progress assumption, so the two sequential components 
must communicate as early as possible. Now we “match” the two histories against 
each other and find that both first have to wait 5 time units and then they can 
communicate. So a common history of wait 5; c?a; |f c!3 is 

(£ = 5 A 3uo • ([a; = uol A \{x = Vq)) • /'{x = 3) 

5.2 Rule System 

For TRSL expressions being in a certain standard form [3], we have developed 
proof rules for deriving their common histories. Some expressions not being in 
this standard form can be converted into the standard form using the TRSL 
proof rules in [11], so in this sense we are able to find the common history for 
more general expressions. 

The rule system defines an expansion relation — > between terms which 
can be DC formulas and applications of some special functions^, assign^, 
inputs, outputs, waits, waitinputs, waitoutputs, o, INs and ORs- The idea 
is that, if Hs{E) — >* (j) for a TRSL if-expression E and a pure DC formula 
(f) then (f) \s ‘A common If-history of E, i.e. Hs{E) 9 (p. The side conditions in 
some of the rules use other expansion relations, =^comm and =^wait, which 
are defined by their own rules. 

In appendix B we list some of the most important rules needed for the case 
study in section 6. 



6 A Case Study 

In this section, we illustrate our verification method on an example: a simplified 
version of the gas burner system proposed in [6] . A gas burner is either heating 
when the flame is burning or idling when the flame is not burning, and it alter- 
nates indefinitely between heating and idling. Usually no gas is flowing while it 
is idling. However, when changing from idling to heating, gas must be flowing 
for a short time before it can be ignited. Hence, there may be a period where 
gas is flowing and a flame is not burning, i.e. gas is leaking. A design of a safe 
gas burner must ensure that the time intervals where gas is leaking do not get 
too long. 

6.1 TRSL Specification 

The specification below defines a design for a gas burner process and assump- 
tions about its environment. The GasBurner consists of three parallel compo- 
nents: MainContr oiler, HeatController and FlameController. The variables gas 
and flame are equal to 1 when the gas and flame, respectively, are on, and 0 other- 
wise. The HeatController senses whether the environment is giving a request (on 

^ The subscript E can be dropped when the considered E is obvious from the context. 
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channel HeatOn or HeatOjf) for heat to be turned on or off, and signals this (on 
channels hon and hoff) to the MainController. The main controller controls the 
flow of gas based on the heat requests it receives and informations (on channel 
flon) about the appearance of a flame. The FlameC ontroller conivols the flame. 
The environment, Env, has a fixed pattern, parameterized with four parameters 
xl, x2, x?> and x4. 

Figure 2 illustrates the communication relations among the four processes. 



Flame- 

controller 



gasoff 

flon 



Main- 

controller 



hon 

hoff 



Heat- 

controller 





floff 


noflame / 




FlOn 


GasOn 


HeatOn 





HeatOff 











Env 




V 




) 



Fig. 2. Communication Graph of the Gas Burner System 



channel hon, hoff, flon. ffoff, noffame : Unit 

channel HeatOn, HeatOff, GasOn, FlOn, gasoff : Unit 

variable gas, flame : {|i : int • i = 0Vi = l|} 

value xl, x2, x3, x4 : Nat axiom xl < 1, x2 > 0, x3 > 1 

value 

MainController : Unit — in hon, flon, hoff 

out GasOn, ffoff, gasoff, noffame write gas Unit, 
HeatController : Unit — >■ in HeatOn, noffame, HeatOff out hon, hoff Unit, 
FlameController : Unit — >■ in FlOn, ffoff, gasoff out flon write flame Unit, 
GasBurner : Unit — ?> in any out any write gas, flame Unit, 

Env : Unit — ?> in GasOn out HeatOn, FlOn, HeatOff Unit 

axiom 

MainController 0 = gas := 0; hon?; wait 30; GasOn!(); gas := 1; 

(flon?; hoff?; gas := 0; ffoff! () 

D 

wait 1; gasoff!(); gas := 0; noffame!()), 

HeatController 0 = HeatOn?; hon!(); 

(noffame? [] HeatOff?; hoff!()), 

FlameController 0 = flame := 0; 

(FlOn?; flame := 1; ffon!(); ffoff?; flame := 0 

D 

gasoff?), 

GasBurner() = MainController() || HeatController() || FlameController(), 
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Env() = wait x2; HeatOn!(); GasOn?; 

((wait xl; F10n!(); wait x4; HeatOfT!()) wait x3), 
GBSystem() = while true do (Env() j} GasBurner()) 



6.2 DC Requirements 

The gas burner system must satisfy the following DG formulas expressing that 
(1) a leak must not last longer than 1 second, and (2) the time distance between 
two leaks must be at least 30 seconds: 

1. □([Leak] ^ < 1) 

2. G(([Leak] • [-iLeak] • [Leak]) => £ > 30) 

Here Leak = gas = 1 A flame = 0, where gas and flame are variables appearing 
in the TRSL specification. 



6.3 Verification 

Below we sketch how our verification method can be used to prove that the 
TRSL specification of the gas burner system, GBSystemQ, satisfies the DG 
requirements given in Section 6.2, i.e. 

1. GBSystemO sat D([Leak] =>£<!) 

2. GBSystemQ sat G(([Leak] • [-iLeak] • [Leak]) £ > 30). 



A Common History of the Gas Burner System 

First we look for a common history formula of the gas burner system. Using the 
proof rules we can derive: 

H {M ainG ontrollerf)) 

H{HeatGontr oiler 0) 

H{FlameGontr oiler 0) 

H{Env{)) 

H{Env{) ][ GasBurnerO) — )■ IN{henv,hjnc,hhc,hfc) — hgb 
El {GBSystemQ) — > {hgb)‘^ 

where^ 

hmc = assignjjQgas h> 0]) • input{hon, _) o 

wait{30) • output{GasOn, ()) o assignjj{[gas i— >■ 1]) • 

{{input{flon, _) o input{hof f, _) o assignsQgas i— >■ 0]) • 
outputlflofffl))) 

V 

{wait{l) • output{gasof f , ()) o assignsQgas i— >■ 0])o 
output {no flame, ()))) 

^ input e{c, _) is a special form of input s{c,x). It is short for [c?]* A 3s : H • ([s]* A 
\s A fl's) 
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hhc = input{H eatOn, _) o output{hon, ()) o 

{input{no flame, -) V input{H eatO f f , f) o output{ho f f , {))) 

hfc = assign([flame i— >• 0]) • 

{{input{FlOn, _) o assign{[flame 1]) • 
output{flon, 0) o input{floff, _) o assign([flame i— >■ 0])) 

V 

input{gasoff, _)) 

henv = wait{x2) • output {HeatOn, ()) o input{GasOn, _) o 

OR{wait{xl) • output{FlOn) o wait(x4) • output{F[ eatO f f , ()), 
wait{x3)) 



^gh 

{{i = x2 A \honl A HeatOnl A FlOn7~\ A \gas = 0 A flame = 0] )• 

(£ = 30 A \HeatOf fl A FlOnl A GasOnl\ A \gas = 0 A flame = 0])* 

{I = xl A Iflonl A FleatOffl A FlOn^^^ A \gas = 1 A flame = 0])* 

{I = x4A \hoff7 A FleatOffl A floffl~\ A [gas = 1 A flame = 1] 

A j^{{gas = 0) A flame = 0))) 

V 

((£ = x2 A \hon7 A FleatOnl A gasoff7~\ A [gas = 0 A flame = 0])* 

(£ = 30 A \noflamel A gasoffl A GasOn7~\ A [gas = 0 A flame = 0])* 
(Z = 1 A \noflamel A gasoff?~\ A \gas = 1 A flame = 0])* 

(Z = a:3 — 1 A \gas = 0 A flame = 0] A j^{{gas = 0) A flame = 0))) 

Hence, is a common history formula of the whole gas burner system 

GBSystemQ. 



Application of theorem 5.2. 

According to theorem 5.2 we can now verify the proof obligations by proving 

\=dc {hgbY □([Leak] £ < 1) and 

\=dc \hgb)‘^ => □(([Leak] • [-iLeak] • [Leak]) £ > 30). 

This can be done by using the following to rule 

\^dc 4* ^ ( 1 ) 

for any n > 0, if \=dc ^ ip then \=dc ^ V' (2) 

\=dc 4F ^ Ip 

and the standard proof rules for DC with super-dense chop. 

7 Discussion 

In this paper, we have proposed how DC and TRSL can be linked together in a 
real-time development method. Our approach for linking these two formalisms 
together was to extend the operational semantics of TRSL with behaviors which 
are DC formulas describing the history of the observables of the system, and 
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then define a satisfaction (or refinement) relation between sentences of the two 
languages in terms of behaviors. 

Our approach can also be used as a general way of linking state-based real- 
time logics together with timed, event-based process algebra languages and is 
new to our knowledge. DC has e.g. previously been linked together with subsets 
of other event-based process algebra languages (e.g. OCCAM [13], HCSP [14], 
SDL [5]), but using another approach: the event-based languages were given a 
denotational semantics in terms of DC formulas. It is very straight forward to 
extend an operational semantics with behaviors and much easier (simpler) than 
giving a denotational DC semantics. This becomes especially evident for larger 
languages providing more advanced language constructs. For instance, using the 
operational approach rather than the denotational approach, it became possible 
to handle lambda expressions and to allow concurrent components to share ou- 
tput channels and input channels (both features provided by TRSL, but not by 
the previously considered languages). The behaviors record fewer observations 
than in the denotational approach making our resulting DC common history 
formulas much shorter, and hence, it also becomes easier to verify that a satis- 
faction relation holds. In the ProCoS approach [6], DC has been linked together 
with an event-based language via a transformational approach: by some rules, a 
DC design (in a certain subset of DC) can be transformed into a program which 
by construction satisfies the DC design. This approach has the advantage over 
our invent- and-verify approach that no proofs should be made, however, it has 
the disadvantage that it is less general: it does not provide the possibility of 
testing whether a given program satisfies a given DC formula. 

Topics for future work include tool support for our verification method. A 
quite promising approach is to define an appropriate subset of TRSL for which 
the common history formulas of TRSL programs can be derived mechanically 
and for which these formulas are in a decidable subset of DC. Hence, if also the 
real-time requirements are formulated in the decidable subset of DC, the whole 
verification process can be done totally mechanically by a model checking tool. 

Acknowledgment. The authors thank Zhou Chaochen, Michael R. Hansen 
and Chris George for their advice on this work and the anonymous referees for 
their comments. 
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A Operational Rules 

Basic Expressions 



p h< skip, s > with <!, 



0 J S ^ with 0 



p h < stop, s > 



e{d) 

vith <i> X stop, s > 



with </) •(fsl A i=d A A /%) 



p h< chaos, s > with 



<C chaos, S ^ with cj> 



Configuration Fork 



p \-< El op E2, s > with 0 A < iSi , S > with 0 op < E2,S > with 0 
where op = f| , [] 



Look Up 



p t [id i-A t;] h< id, s > 



'ith <l> ~^< V,S > 



with <() 



p \- < id, s t [id v] > with 0 A< V. s t [id i)] > with 0 
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Sequencing 



p h < Bi ; B 2 , s > with cj> (< Ei,S > ; E2) with I 

P I- g with 4> ^ Q'with 

p h (a ; E) with 4, (g' ; E) ^itj, 

P^ with ft) ^ ^ E, S > with <j) 



Assignments 



p h< X := _B, s > with 4 , ^ X :=< E,s > with 

P I- g with 4 > ^ Q^'with j.' 

p h (x := g) with -> (x := g') „jth 



p h (x : = < V, s >) with 4, ->■< 0 . s t [2: !->■ «] > with 4, . A 



Waiting 



p h< wait E, B > with 4> — t (wait < E, s >) with 4, 
P H g with 4 , ^ a 

p h (wait g) with 4, (wait g') with 4,' 



/\ s(^) ! 

p h wait < (rf+ rf ), s > with 4> )■ wait <d , s> ^ a a jB^s) 

when d > 0 



p h wait < (0), s > with 4, X 0. s > with . 



Input 



p h< iet t = c?x in B, s > with 4, — 1< -E[ 0 /t], s f [a: i-t w] > with 4> , a 

p\- <. let t — c?x in s > with <j> 

let t = c?x in E[t + d/t], a > ^ a A 



Output 



p h< iet t = c ! B in B, s > with — t (let t = c ! < B, s > in B) with 4> 
P H g with 4 g'with 4,' 



p h (let t — c ! CK in E) with </> (l^t t — c ! a' in E) 



'^ith (j)' 



p h (let t ^ c \ < V, s > in E) with — ^< E[ 0 /t],s > with a /fe) 

p h (let t — c \ < v,s > in E) with <p 

(let t = c ! < D,s > in E[t + d/t]) ^ a a 
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Internal Choice 



P n /?) with ^ Oi with I 

with ^ 



External Choice 

P H a with 4> ^ a. 



P H (a with 4. [1 /3 with 0" ) 
C/^ with 0'^ D ^ with 0 ) 



vith 

vith 



u ' u /5 *4^3 a' 

P H a with 0 > a , p h with 0" >■ P with 0" 



p 


h a 


with <f> 


[ 1 / 3 , 


with 0^^ 


e{d) , 

^ with 0' 


^ with cj)'" 




p 


with 4 > 


" D a 


with 0 


f}' 

^ with 0^‘ 


" 0 with 0' 








p h a 


with 0 


^ ^ with 0^ 




p 1 - 


(a , 


i^ith <f> 


Q ^ with 0" ) 


(“'with 0' 


W 0 with cf" ^ 




(/3 


with 0 " D “ 1 


iwith 0 ) 


(/5 with 0^^ 


0 “ with 0^ ^ 


p 1 - 


< V, 


, S > w 


ith 0 


D ^ with 


0' -^< t/.s > 


with 0 




^ w 


ith (j)* 


1 < ’Z, 


s > with 0 ->■< V,S > 


with 0 



Parallel Combinator 



p h < i?i II E 2 , S > with 0 — > 

< -El, s \ var{E2) > with 0II s \ (var(E-i) U var(E2)) ||< E2. s \ var{Ei) > with , 





P H a with 0 — >■ a 


,p ^0 with 0" 


->-/ 3 'wi 


th <P"> 


P 1- 


a V 


v^ith 0 


II S II /3 with 0" 


^ with <j)' 


II * II 


^ with <p'" 




/3„ 


/ith 0^^ 


II s II a with 0 


^ with 0'" 


II II 


^ with 4>' 










/ 












p\- a with 0 


^ with 4>' 






P 1- 


a V 


tfith 0 


II s II /3 with 0" 


A / 

^ ^ with 0' 


II « II 


^ with <f>" 




/ 3 „ 


/ith 0^^ 


II s II a with 0 


P with 0" 


II » II 


^ with </>' 




P 1- 


e((i) , 

Q: with 0 >■ Q; 


, p 1“ ^ with (p' 


, 


with <pf" 


P 1- 


a V 


tfith 0 


II ® II /3 with ef}" 


e{d) , 

^ “ with 0' 


■ II ^ II 


3 'with 0'" 




/ 3 „ 


/ith <t>'^ 


II S II a with 0 


/ 3 'with 0' 


n II « 


II ^ with 0' 






( Sortd{a) n SortdiP) 


= 0 ;1 






when < 


Sortd 


(a) n SORTd = 


0; \ 










[ Sortd 


(/ 3 ) n SOETd = 


0 J 






P 1- 


a V 


»/ith 0 


II S ||< V, s' > ^ 


i/ith <p' ^ wi 


th 0 II 


® II «'with 0' 




< 'P, s' > 


with 0^ II ^ II ^ 


with 0 -> s'with 0' II 


s II a with 
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a with a , 



P H a with 4 , 

^ with 4 ^' 



with (f}" 
^ with d) 



vith (f>' 
rith 4 >" 



^ with <!}^^ 
^ with 4 i' 



ph <v,s" > with 0 II S II s'with 4' 
®'with 4 ' II ® ll< * 



e , 

-¥<. 'U,sUs Us )> 
>•< 1?, s U s^ U s^^ > ^ 



with (0 A 4>') 
'ith (0 A 0 ') 



Interlocking 



p h < iSi -|l -B2 , S > with 4 — > 

< -El, s \ var{E2) > with 0-H s \ (var{Ei) U var{E2)) -H < E2, s \ var(Ei) > with 4 



p 1- 


with 


—A. ' 

^ with 0^ 


.pH /3, 


vith 0^^ 


^ with 0 "' 


p h a 


with 0 


"H ^ "H /5 with 0 " 


A 


ipith <j>' 


■H ® "H ^'with 4 '" 


/3 


with <t>'^ 


-H s -11 g with 0 




rith 0^^^ 


-H ® -H “'with 0' 






P H a with 0 


e , 

^ ^ with (j)' 




p h a 


with 0 


"H ^ "H /5 with 0 " 


A 


iPith 0^ 


"H ^ "H /5 with 0 " 


/3 


with <t>'^ 


-H s -H g with 0 


A/3„ 


rith 


■H ® "H “'with 0 ' 














P 1- 


g with 0 i g with 0 ' 


.pH /3 


with 0^' 


’ ^ with 4 "' 


p h a 


with 0 


"H ^ "H /5 with 0 " 




with 0^ 


■H ® "H ^'with 4 "' 


/3 


with 0^^ 


-H s -H a with 0 




with <t}'" “H “H with 0 ^ 



when Sortd(<y) H Sortd(/3) — 0 



P \- Ot with 0 ^ with 4>' ^ with 0 -«s-l|s' with (j)' 

<i V , S 0 /-[] S “H Of with </} —^ s “H S “H with 0 

with 4 ^ a with 4 ' 

P H a with 0 -H s -H s'with 4 " ^ “'with 0' -H -H ®'with 4 " 

®'with 0" “H ® "H “ with 0 -> s'with 0" "H ® "H “'with 0' 



p h < D, s" > with 0 "H S -H s'wi 



ith <i>' 



vith 0 ' 



,/ -H s "H < s" > with , 



< «, s U s' U s" > with 
< 1 ), S U s' U s" > with (0 A 0') 



Functions 



P^^ El E 2 , S > with 0 ^ El, S > E 2 ) with 0 

p I- g with 0 4 g'with 0' 

p h (a E) 

with 0 ^ (“' E) with 0' 



p \-< \ id : T • E, s > with 0 A< [A id : r • E, p ], s > with 0 



p h (< [A id : r • El, Pi ], s > E2) with 4 A ([A id : r • Ei , pi] < E2, s >) with 4 
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p OL with I 



p h id : r • E, Pi ] a) „ith 4, -t ([A id : r • B, pi ] a') 






p h ([A id : r • B, Pi ] < v, s >) wuh 4, ^ ([A id : t » < E, s >, pi ] v) ^ 

Pi t [id t-i ti] h a with 4, ^ “'with 4,' 
p h ([A id : r • a, Pi ] v) with 4, ([A id : t • a', pi ] 11) „ith 4,' 

Pi t [id i-> ti] h g with 4, ^ <v',s> with 4,' 
p h ([A id : r • a, Pi ] v) with 4, -^< s > with 4,' 



Let Expressions 



p h< let id = Bi in B2, s > with 4> (let id =< Bi, s > in B2) with 4, 

P I- “ with 4 > ^ “'with 4,' 

p h (let id = a in B) with 4, -i (let id = a' in B) „ith 4,' 



p h (let id = < 11, s > in B) with </.—>■< B[t;/id], s > „ith 4> 



If Expressions 



p h< if B then Ei else E2, s > with 4, (if < E, s > then Eielse B2) with 4, 

P I- “ with 4 > ^ “'with j.' 

p h (if a then Ei else E2) with 4, -i (if then Bi else B2) with 4,' 



p h (if < true, s > then Bi else B2) with 4, —i < Ei,s > with 4> 



p h (if < false, s > then Bi else B2) with 4, — i < E2, s > with 4, 



While Expressions 

/O h < while El do £J 2 , s > with 

A ( if < El, s > then £J 2 ; while El do E 2 else skip) with <t> 

B Proof Rules 

Some Shorthands 

(0r= V 

j^Nat 



0" = (0 o ... o 0), /or n > 1 

n times 



Linking DC Together with TRSL 
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Rules for H 



Hs{x := v) — > assigns{[x n]) 
Hs{c?x) — > inputs{c,x) 



Ri;(wait d) — > waits{d) 
Hs{c\v) — > output s{c,v) 



Hs{Ei)^cj,i ,Hs{E2) 





Ri: (while true do E) — > cfE 




Hs{Ei n E2) — > ORs{(f>i,(j)2), Hs{Ei\\E2) — > <f>i V <(>2 



Hs,iEi)^<t>i,ie{l,...,n},Ei = E\[j 



j'e{l,. .,n}\{i} 



var(Ei) 



Hs{Eri{E2 II ... II E„))^IN: 



INj:{cj)i, (j)„) 



Rules for Various Functions 

1. assigns{sl) — > 3s : E ■ (\sA /'(s f si)) 

2. inputs{c,x) — > [c?]* A 3s : X",!) • ([s]* A \s A j^{s t v])) 

3. output s{c,v) — >■ [c!]* A 3s : X • ([s]* A \s A ^s) 

4. waits (d) — > .^ = dA3s:X-([s]A \sA j^'s) 

5. waitinputs{c) — ^ [c?]* A 3s : X • ([s]* A \s A j^s) 

6. waitoutputs{c) — >■ [c!]* A 3s : X • ([s]* A \s A /?'s) 

Rules for o 

o 0'” describes a common history for a sequential composition (taking into account 
that the first expression may not terminate). 

1. input s{c,x)o (j) — > input s{c,x) • <j) V wait input s{c) 

2. output s (c, v) o (f> — > output s{c,v) • 4> V waitoutputs{c) 

3. waitinputs{c) o (j> — > waitinputs{c) 

4. waitoutputs{c) o cj) — > waitoutputs{c) 

5. waits{d) o (f> — > waits{d) • 4> 

6. (v?i V if2) o 4> — > {pi o ()>) V {p2 ° <j>) 

7. (j>i o <f >2 — > 4>i» 4>2, when (jii ^ {t = 0) 

Rules for OR 

“ORs{4>i,4'2)” describes a common history of an internal choice. 

1. (j)o ORs(pi,P 2 ) — > ORs{(j)opi,4>°Pi) 

Rules for IN 

“INsitjn, 02, ..., 4’n)” describes a common history of a collection of parallel sequential 
processes interlocked with its complete environment. 

1. INs{ORs{4>l, 02), 03,..., 4‘n) INs{4>l, 03,..., 4‘n) V INs{4>2, 03,..., 0ri) 

Note, 3s ; X • 0[s] means that there exists a X-store s such that 0[s] is true. 
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2. INs{(j^l,...An) 

* I ^ E (01 5 5 ■•■ ! ) ■ ■• ) 0n) 

i,j € {l,..,n},iy^j 

INEi<j>i, 4>j) =>COMM 00 • 0 ') 
when there exists i,j G {1, ..,n} with j for which 
INsitpi, 4>j) =^COMM <p0 • INE{4>i, 4>j) 
for some 0o, 0( and 0'-. 

3. INsHwaitsiiS) • 0l) V 012 V ... V 01m,i , 021 V ... V 02m2, V ... V Onrrin) 

{waits{S) A (l?12 V ... V l 9 lmi) A (l?21 V ... V ■&2m2) A ... A V ... V 
• INe{<I>i V 0 'i 2 V ... V , e'21 V ... V , ..., e'„i V ... V 
when: 

a) for all {i,j) G {l,...,n} x {!,..., mi} with (i,j) 7^ (1,1), 

INs{waitEi{S) =^wait {waitE{S) A'dij) • INE{<!)i, 9 'ij), for some 

i?ij and 6 [j\ 

b) there exists no (h,i),{j,k) G {l,...,n} x {l,...,n} with h 7^ j, for which 
INE{ 0 hi,djk) =^coMM 9 q» INE(d'hi, 9 jk) for some 9 o, 9 hi,Sjk. 

4. INE{assignEi{s) • 0i, 02, ..., 0n) — >■ assignE(s) • INe{<I>i, 02, ..., 0n) 

5. /Ys(} ], 02, ..., 0„) >■ /Yx’( 02, ..., 0n) 

6. 1 Ne{<I>) 0 

7 . INe[--,(Ih, •••, 0 t :---) — > INeI-.-Aj, .••, 0 i,---) 

8 . ... 

Rules for =^comm 

“ 7 Yi;( 0 i, 02) =^coMM 0» /An (01, 02)” holds if two concurrent components (descri- 
bed by 01 and 02) are able to make a communication (described by 0) leading to two 
new concurrent components (described by 0 i and 02). 

1. INE{{inputEi{c,x) V (pi) o 01, {output e2{c,v) V (P 2 ) o 02) =^comm 
assigriE{[x i-A- v]) • IN{(f)i, 02) 

2. ... 

Rules for 

“ 7 Yi;( 0 i, 02 ) =>wAiT 0 • 7 Yi;( 0 i, 02 )” holds if two concurrent components (descri- 
bed by 01 and 02) evolve a time_measurable event (described by 0) leading to two new 
concurrent components (described by 0i and 02). 

1. INE{waitEi{ 5 ) • (t>i, input e2{c,x) o 02) =>wait 
{waitE{S) A }c?]) • 7 Ys (01, input 1 : 2 ( 0 , ®) o 02) 

2 . INE{waitEi {5 • cj)i, output e2{c,v) o 0i) =^wait 
(u>aiti;(( 5 ) A [c!]) •INe{ 4 >i, output e2{c, v) o cj)2) 

3. I N E{waitEi{5i) • 4>i,waitE2{5i -I- ^ 2 ) • 02) =>wait 

waitE {Si) • I Ne (01 , waitE2 (^2 ) • 02 ) 



® This rule expands the common history of a concurrent composition as a disjunction 
of its possible communication behaviors, when an initial communication is possible. 
® This rule expands the common history of a concurrent composition in which all 
components can wait for 5 time units and no initial communication is possible. 
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Abstract. In this paper we investigate timing diagrams as a means to 
specify causal dependencies. We introduce a stylized graphical represen- 
tation of timing diagrams for which we define a formal basis. Further- 
more, we compare our approach with well-known approaches from the 
area of program verification and show the semantic relationships. The 
major aim we follow by this work is a seamless integration of hardware 
design and software development providing a common semantic basis e.g. 
for verification. Therefore, the semantic relationships to frameworks for 
program verification show that the combination of these approaches is a 
good starting point for further development. 

Keywords: causal dependencies, timing diagrams, hardware and soft- 
ware design, formal semantics, integrated verification, relational seman- 
tics, dynamic logic. 



1 Introduction 

The development of rigorous and formal methods is marked by the fact that 
nearly each area started to develop its own methods from scratch. Thereby, 
we are dealing with a bunch of different formal methods mostly developed for 
treating specific aspects of systems, e.g. for programming, databases, telecom- 
munication equipment, and hardware devices. Not only the large number of these 
approaches and their variants but also the fact that systems do not just consist 
of single “aspects” cause the necessity to integrate approaches for different as- 
pects in order to offer a more homogeneous way of supporting the design and 
development of systems, in particular when hardware and software have to be 
considered together at the same time. 

The design of embedded systems, telecommunication systems and other com- 
puter controlled devices can roughly be divided into two major parts: hardware 
design and software development. Both areas have their own peculiarities. Hard- 
ware devices, e.g. integrated circuits, are mostly non- sequential and have to meet 

* Supported by the DFG under project no. NE 592/4-2. 
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real-time constraints and time dependencies like synchronization. Special issues 
considered in software development are termination of programs, usage of re- 
cursion etc. The investigations of common theoretical foundations is a must for 
overcoming the above-mentioned heterogeneity because all aspects of engineering 
base on the same concepts: on processes, on states, on data etc. 

Timing diagrams form a simple mechanism which can be used in hardware 
design. For example, specification of integrated circuits (ICs) is commonly based 
on timing diagrams so that electronic engineers are supposed to be familiar with 
this specification technique. The next section informally introduces the concept 
of causal dependencies in order to stylize timing diagrams and to complete their 
expressibility for the use in specification. A graphical notation will be presented 
for the specification with causal dependencies which is easy to interpret. Section 3 
presents a more precise introduction to the principles used herein by defining 
syntax and semantics of that graphical notation. The main goal of this paper is 
tackled in Section 4. In this section the relationship of our specification technique 
using causal dependencies and widely spread program verification techniques is 
investigated. We conclude by briefly discussing further related work and pointing 
out future work. 

2 Timing Diagrams and Causal Dependencies 

Timing diagrams are diagrams like the one in Fig. 1 depicting a serial 5 bit 
character transmission. A low level bit which is called start bit announces a 
character. Then, the five data bits follow, and a high level bit called the stop bit 
closes the transmission. 



Start Bit Bit Bit Bit Bit Stop 




Fig. 1. Asynchronous serial character transmission — 5 data bits, one stop bit. 

However, not only the behavior on one wire is interesting but also the tem- 
poral relationship between several wires, i.e. synchronization. Fig. 2 shows how 
to express this by means of a dashed line. The left picture could be part of a 
diagram contained in a technical specification of an integrated circuit and the 
right picture is the stylized form of the left picture. The intuitive meaning of 
these pictures could be the following one: The level on the lower wire switches 
from high level to low level and then a data transmission on the upper wire be- 
gins. The dashed line equates time points on several processes, thus expressing 
synchronization. 

Pictures like those of Fig. 2 can express scenarios. But this is usually not 
sufficient for specification purposes. Specifications have to express e.g. that data 
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Data 



Triggering 




Fig. 2. Part of a timing diagram. 



transmission requires the falling level on the lower wire. This is a logical con- 
sequence. In order to emphasize this relationship we will frame the premises as 
shown in Fig. 3. These logical consequences are called “causal dependencies” in 
the sequel. 




Fig. 3. Causal dependency in a timing diagram. 

There are two kinds of causal dependencies: causal dependencies of type 
requires and of type eauses. Fig. 4 contains an example for each of these kinds. 



3 Syntax and Semantics of Cansal Dependencies 

3.1 Signatures and Models 

Firstly, we fix ground sorts and methods. Intuitively, methods are actions repre- 
senting time intervals, i.e. which can begin and can end. The term “method” can 
be used, e.g. in order to formalize database transactions or computer programs. 

def 

Definition 1 (Signature.). A signature is a pair E = where Ss is 

def 

a set of ground sorts and = {i^s,u,v \ u,v G is a family of methods. 
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Fig. 4. Two examples: Causal dependency of type requires “The coffee vending ma- 
chine dispenses a cup of coffee only if one euro was inserted” and causal dependency 
of type causes “Pressing the button causes the test routine to start” . 

Herein and hereafter, S* refers to the free monoid over any set S, i.e. the set 
of sequences Xi . . . Xm with m > 0 and Xi G S for each i G {1, . . . , m}. These 
sequences of ground sorts are called sorts. 

Methods R G ^s,ui...u.^,vi...v„ where Ui G and vj G for all 
i G 77i} and f G {1, . . . , n} are presented by boxes as shown in Fig. 5. 

The left-hand side of a box represents the time before execution of the action 
corresponding to the method and the right-hand side of a box represents the 
time after executing this action. Please note that Ui G and Vj G Sx: were 
never demanded, i.e. arrow bundles can be presented by one arrow as shown in 
the picture on the right-hand side of Fig. 5. 




Fig. 5. Pictorial Representation of a Method. 



The semantic representations of methods are binary relations. 

Definition 2 (Structure.). Given a signature S. A structure w.r.t. this sig- 
nature or briefly a E-strueture Xi is a map assigning a set of states 

for each ground sort X G Ss, which is freely continued to sorts so that 
X^ X ... X for each sort u Xi . . . X^ and assigning a binary 
relation R-^ G fp x v^) of actions for each method R G Gx;,u,v 

Hereafter, the following notation will be used for relations of actions: 



def 



(x,y) G R 
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X ^ y states that the state y is reached by action R from x as well as in 
many other approaches to defining processes like transition systems [23]. Howe- 
ver, there is a subtle difference to usual interpretation of that relation in order 
to more easily deal with parallelism. Suppose as an example two actions ON 
and OFF, respective states and a binary relation shown in Fig. 6. Herein, its 
interpretation is a process which creates two parallel successor processors one by 
action ON and the other by action OFF in each state. In the most other pro- 
cess definition techniques like transition systems the branchings would express 
non-deterministic choice rather than parallelism. 



OFF 



OFF • , ON 
• \ ON 



OFF • . ON 

• • 

OFF / ■ 



ON 



Fig. 6. Infinitary Binary Tree. 



3.2 Terms 

Methods can be composed by the means shown in Table 1 to terms whose in- 
terpretation in a structure Ai is defined as follows: The superscript will be 
omit herein and hereafter: 

id„ 

X y 
R;S 

X ^ y 

(g) Ri 

{xi\i€ I) (yi \ i e I) 

A Ri 

i€I 

X ^ y 

The shadowed boxes in Table 1 represent not only methods but also terms 
so that this is a recursive definition. 

The constructions introduced in Table 2 and Table 3 are defined as macros. 
In the following definitions tt„^„ is the par-operation with m = 0, cf. Table 1. 



,[k] 

\vi 


1 


m 

i: = l 


f idt,^ 


i = k 
i k 


rrpl 

(Ui 


1 i6{l... 


m 

.„))=' ( 8 ) 
z: = l 


f 

1 


i = k 
i ^ k 



x = y 



3y. (^x A- y Ay A- 



Ri 



Vi e I.x^ -4 y, 



Vi G I.x ^ y 
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Table 1. Operations on Hypergraphs. 




^m,v — /\ I 

k-.^l 

m 

V7 A 

Vm,« — /\ 7J"^„ I 

fc: = l 

Intuitively, terms represent scenarios. The skp-operation in Table 1 refers to 
an operation which does nothing. The sequential composition seq of terms R 
and S correlates to the action where S begins as soon as R ends. Independent 
partial scenarios are represented by the con-operation; and parallel composition 
of methods R and S whose corresponding action is the simultaneous execution 
of R and S is presented as par-operation in Table 1. Fig. 7 shows an example of a 
term. The frames in terms T's,u,v should cut off the nodes determining the sorts 
u and V. This is necessary, sometimes, because these sorts could be ambiguous. 

3.3 Propositions 

Now, we can start to stipulate requirements of which three kinds can be distin- 
guished. However, the propositions of the first kind, the equations, can be defined 
via the propositions of the other kinds, which are called causal dependencies. 
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Table 2. Derived Terms — part i. 







Vi 


Ml 










Vk-1 


Mfe-1 






u — 




— ^ Vk 


Mi >■ 




-^V 






Vk+1 


Mfc+1 










'^m 


Um 






def 






def \k' 
= 7T/ 
(u 


1 


m})> 



Table 3. Derived Terms — part ii. 




Fig. 7. Producing an Electronic Device. 
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As mentioned before, causal dependencies can be of two types (cf. Fig. 8 and 
Fig. 9). 




Vx, y3z. 



R 

x^y 

s 

y^z 



Fig. 8. Causal Dependency of type causes. 




Vi/, z.3x. 



y ■ 



z 

y 



Fig. 9. Causal Dependency of type requires. 



4 Relationship to Program Verification Systems 

In this section we show that the semantic foundations of well-known program 
verification techniques as well as the relational semantics given by the structure 
concept from Definition 2 are equivalent. 

The representation of timing diagrams as causal dependencies benefits from 
this strong relationship to program verification techniques. This correspondence 
helps to overcome the heterogeneity between representations via timing diagrams 
and program verification techniques. 



4.1 Axiomatic form of Hoare Triple Logics 

Hoare triples like {V} R {T} express partial correctness of programs R under 
the precondition X and postcondition Y . Regarding R as method of the approach 
in this paper, partial correctness is given by the following statement: 

{X} R {F} 44 (1) 

y GY 

i. e. whenever the current program state fulfills the precondition X and the 
program R terminates then a state is reached fulfilling postcondition Y. Partial 
correctness does not require termination of the program. 
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The new structure concept. Below, another equivalent form of Definition 2 
is presented which bases on an axiomatization of partial correctness. The notions 
“Galois connection”, “GABA” and “tensor” will be explained subsequently. 

Definition 3 (Structure.). Given a signature E. A structure w. r. t. E or, 
briefly a E -structure M is a map 

— assigning a complete atomic Boolean algebra (GABA) X-^ to each ground 
sort X € Se 

— freely continued to a map assigning = Xf^ 0 ... 0 Xf^ to each sort 
u = Xi...X^ 

— and assigning a Galois connection between and for each method 
R C Ge,u,v 



State conditions. The preconditions and postconditions will be formalized as 
usual by Boolean algebras. Boolean algebras which are isomorph to a power set 
algebra fp (A) with a set A are called complete atomic Boolean algebra (GABA). 
All finite Boolean algebras are by virtue of Stones representation lemma [25] 
complete atomic Boolean algebras. The singletons {a} with a G A are called 
atoms. Subsequently the attention is restricted to power set algebras. 

The elements a € A represent the states which correspond to the states of 
the structure concept according Definition 2. a G X with X G ^ (A) expresses 
that the state a obeys the condition X. 

The tensor of a family 

(b, = ^{A,) I ze/) 

of power set algebras is the following power set algebra: 

(g)-B/= 

i&I \i&I / 



Galois connections. Hoare triples are axiomatized by Galois connections bet- 
ween complete atomic Boolean algebras. This subsection introduces the concepts 
for the more general case of complete lattices. [1] introduces the most general 
form of the concept of Galois connection. 

Given two complete lattices U and V. In this context a Galois correspondence 
is a relation R CUxV fulfilling the following axioms where C denotes the lattice 
order, n denotes the infimum operation and U denotes the supremum operation. 
{A} R {F} states {X,Y) G R: 



X' <ZX {A} R {F} 

{AT^n 

VA e X. {A} R {F} 

{UX} R {F} 

VFe 2).{A} R {F} 



VA,A',F,F'. 
VX, F- 
VA,2).. 



{A} R {nm 



Y CY' 
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The terminus of Galois connection between complete lattices could be defined 
also in two other ways. There are three forms of a Galois connection R between 
complete lattices U and V: 

— the already mentioned relation i?, 

— infimums (= fi-operation) preserving functions RR between V and W, 

i. e. functions fulfilling for each 2} C y the equation = 

— supremums (= U-operation) preserving functions between U and V, 
i. e. functions fulfilling for each C X the equation (IJ X) = 

U{i?^ W I xgx}. 

The latter functions can be obtained by the equations: 

I 1^} ^ |y}} (2) 

I {X} i? {F}} (3) 

The following equation describes how to obtain the relation from the func- 
tional forms of Galois connection: 

{X} R {F} R'^ (X) C F (4) 

^ X CR^ (F) (5) 



Lemma 1. (2) and (5) as well as (3) and (4) are bijections. 

The equivalence of the structure concepts. A structure according Defini- 
tion 2 can be obtained by this equation for all methods R: 

x^y y € R^ ({x}) (6) 

A structure according Definition 3 can be obtained from a structure according 
Definition 2 by this equation: 

R^ (X) = {y\3xG X.x 4 2 /} (7) 

Lemma 2. (7) defines a supremums preserving function. 

Lemma 3. (7) is equivalent to (1) 



Lemma 4. (1) and (6) form a bijection. 
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Now, for all methods and terms there are four forms to define their semantics. 
The four forms for the identity are 



{X} id„ {F} ^ 



X CY 

Y 

X 



(id.)"W = 

id„ ^ ^ 

X —f y X = y 

The sequential composition can be described as follows in all four forms: 



{X} R-S {Z} ^ 3F({X} R mA{F} 5 {Z}) 
{R]Sf{Z) = R^{S’^{Z)) 

{R-,S)^{X) = S^{R^{X)) 



R;S 

X ^ Z 



3y. ( 



x^yAy^z] 



The equation proposition between terms can be defined in these four forms: 

{X} 5 {F} 



i? C 5 



VX,F-{x} ^ |y| 

VX. {R^ (X) C 5"" (X)) 
VF. (5^ (F) C r!^ (F)) 



yx,y. 



R 

x^y 

s 

x^y 



4.2 Dijkstra’s wlp Calculus [5] 

For a Galois connection R representing a program the infimum preserving fun- 
ction RP is the wlp operator which is used as semantic base for Dijkstra’s wlp 
calculus (wlp stands for weakest liberal precondition). A liberal precondition for 
a program i? is a condition which is fulfilled if R does not terminate. 

4.3 Quantalian Semantics [2,21] 

Given a signature the expressions obtained from methods and the operations id 
and seq of Table 1 and a construction principle which is not contained in Table 1 
yield a quantalian structure on methods. 

Definition 4 (Quantal.). A quantal Q is a complete lattice with a constant 
idg € Q and an operation _;_€QxQ — forming a monoid, i. e. obeying 
these conditions for all R, S,T G Q 



R; S; T = {R; S);T = R; (S'; T) 



Associativity. 
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Neutrality of idg. 



R] idg = R 
idQ-,S = S 



and fulfilling for each O C Q 



R:\/£l = \/{R;Q | Q € 0} 
\/£l-,S = \/{Q;S I ge0} 



The additional construction principle has the following semantics in all four 
forms: 



4.4 Dynamic Logics [12] 

Dynamic logics are considered only semantically, herein: Xq and Yq stand for 
sets of states. Any set £ fp (Fq) is mapped to [R]Y G *p (Aq) and to (R) Y G 
tp (Aq) for programs R, such that [i?j is an intersection preserving map and (i?) 
is an union preserving map. The intuitive meanings of these junctors are: (i?) Y 
is the set containing all those states from which one can get by i? to a state 
obeying condition Y and [i?j Y is the set containing all those states from which 
one cannot get by R to states which do not fulfill Y. More formally, using the 
relational semantics as introduced in Definition 2 these junctors are defined as 
follows: 




V Ri 



X ^ y 



3i G Lx -4 y 




R 




There are analogous constructions for statements about the past: 



R 
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Now, the relationship to the semantics of this paper can easily be provided: 

X C[R\Y J]^X C Y 

^ {X}J^{Y} 

{R)Y CX Y C [R]X 

^ {-X} R {-y} 

Obviously, for each Galois connection R the map X assigning to -•R'^ 
is a infimum preserving function. For each Galois connection by virtue of logical 
negation another Galois connection correlated to this infimum preserving func- 
tion as mentioned before, the Galois connection R can be defined as follows in 
all four equivalent forms: 

{y} R {X} 
if (X) 
ifiY) 

R 

y^x 

This map is involutionary: 



Using this map all four above-mentioned constructions can be expressed by me- 
ans of Galois connections: 

[i?] y = rT' (y) 

Xi^x = R^ (X) 

[i^x = (X) 

{R)Y = Tt{Y) 

Beside these statements, in dynamic logic, there are further expression means 
for iteration and conditionals in programming languages. They are also impor- 
tant for usage in timing diagrams. However, this topic is worth to be dedicated 
to an own investigation. For the purposes of this paper it is not necessary to 
consider such expression means, just because there is no counterpart in the kind 
of timing diagrams we are interested in. 



^ {-X} R {-y} 
= -^R^ (-X) 

= ^rT' (-y) 



R 

x^y 






4.5 The Semantics of Causal Dependencies 

Gausal dependencies of type causes like that in Fig. 8 can also be expressed 
by the formula [i?] (S) tt in dynamic logics where tt is the “true” proposition. 
[S'](i?)tt expresses causal dependencies of type requires as shown in Fig. 9. 
Gausal dependencies can also be expressed by Hoare triples if we accept second 
order statements: 



58 



J. Fischer and S. Conrad 



VX.- 



{tt}i?{X} 



is the semantics of causal dependencies of type causes and causal dependencies 
of the type requires can be expressed as follows: 

{tt}i?{y} 

The expressibility of dynamic logics is exceeded by the fact that the par- 
construct in Table 1 cannot be expressed in dynamic logic. However, it is not 
hard to find a respective extension of dynamic logics because there is a direct 
correspondence of dynamic logic and the relational semantics used in Definition 2 
can be recycled by this definition from the junctors of dynamic logics: 

X 4 y y e {R) {x} 



5 Conclusion 

5.1 Related Work 

There is a flock of approaches to describe parallel processes. [23] contains an 
extract of the entirety of “models of concurrency” . Processes can be described 
declaratively, e.g. using temporal [8,24], dynamic [12] and other logics and using 
Hoare triples [13]. On the other hand, processes can be defined operationally, 
just as in programming languages, CCS [15], CSP [14], ACP [4], the “chemical 
abstract machine” [3] and other so-called process algebras, and Petri nets [19]. 

Causal dependencies play an important role in this paper. Other approaches 
to define processes using causality concepts are event structures [16,17,26] and 
Chu spaces [11,18]. The causality concept which is used in these approaches cor- 
responds with the type requires of our approach. We added the causal dependen- 
cies of type causes because we cannot do without them in most of the practically 
relevant cases. The principal concept of both event structures and Chu spaces 
is the event concept. Events are supposed to happen at mostly once during a 
process lifetime. Thus, for non-trivial processes the number of events being in- 
volved during the process lifetime is infinite. Specifying processes this fact has to 
be considered because in specifications only finitely presented statements can be 
used. This is another reason why we introduced the concept of causal dependen- 
cies. A counterpart of the conflict relation treating non-determinacy postulated 
by event structures is still under investigation. 

Timing diagrams were already formalized for instance in [22] for the same 
purposes as in this paper. [22] contains also a semantic description using a tem- 
poral logic. We decided to go another way. Roughly speaking, temporal logics 
are logics describing the properties of temporally ordered states. Causal depen- 
dencies as well as the program verification techniques emphasize the dynamic 
aspects. They handle with methods, their composition to complex scenarios and 
synchronization. These issues are also to the fore for specification based on ti- 
ming diagrams. 
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5.2 Discussion 

This paper is the result of searching for a precise semantics of timing diagrams. 
Timing diagrams form a declarative specification style already used by elec- 
tronic engineers, e.g. describing the functionality of integrated circuits. Timing 
diagrams are characterized in [22] as “graphical specification language with an 
intuitive semantics, which is especially appropriate for the description of asyn- 
chronous distributed systems such as hardware designs”. There are other for- 
malizations for timing diagrams, for instance in [22] where timing diagrams are 
translated to temporal logics. In contrast, we prefer a relational semantics closely 
related to program verification techniques like dynamic logics. For that, there 
are two main reasons: The close relationship to program verification techniques 
raises the hope to overcome the heterogeneity between hardware and software 
design by a common semantic base. The other reason is that timing diagrams 
rather express dynamic aspects as scenarios and their order (just like the rela- 
tional semantics introduced in this paper) than properties of temporally ordered 
states as in temporal logics. 

In addition to the work presented in this paper, we have already developed 
a module concept for our approach [9] using the well-known principles from 
algebraic specifications [6,7,20]. Real time issues and temporal ordering are still 
subject of investigations. 
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Abstract. This paper presents a formal language for the design of 
component-based enterprise system. The language (StAC) allows the 
usual parallel and sequential behaviours, but most significant is the con- 
cept of compensation that allows a previous action to be undone. The 
semantics of the language is given by an operational approach. The speci- 
fication of a system is composed by a set of StAC processes that describe 
the behaviour of the system and a set of B operations that describe basic 
computations. Operational semantics is used to justified the integration 
of StAC processes with B operations. 



1 Introduction 

The work presented in this paper is the result of the collaboration of the DSSE 
Group with the Transaction Processing Design and New Technology Develop- 
ment Group at IBM UK Laboratories, Hursley. The collaboration has been con- 
cerned with approaches and techniques for component-based enterprise system 
development. 

So far, with support from IBM UK Laboratories, we have defined a formal 
design language suitable for a heterogeneous distributed environment. IBM im- 
posed some particular features on the language: 

— The target enterprise solution should be built by stitching together Enter- 
prise Java Beans [7] (EJBs). 

— The language should allow sequential and parallel composition of behaviours. 

— It should be possible for earlier actions to be undone, which is called “com- 
pensation” , whereby the system keeps track of the compensations that need 
to be executed if part of a process is to be aborted. 

The IBM group believes that compensation gives more flexibility than the tra- 
ditional commit-rollback approach to transaction processing. This flexibility is 
necessary for the heterogeneous distributed environment on which modern ent- 
erprise systems operate. Instead of restoring the system to the state before ac- 
tivities where performed in the case of abnormal events, activities can have a 
compensation activity associated with them. 

The main goal of our collaboration with IBM was to define the semantics of 
compensation, which is a complex concept. The complexity arises in particular 
because of the combination of compensation with parallel execution. 



W. Grieskamp, T. Santen, and B. Stoddart (Eds.): IFM 2000, LNCS 1945, pp. 61—76, 2000. 
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In this paper we define a formal language for the design of heterogeneous 
distributed systems, which we called StAC (Structured Activity Compensation). 
In this approach the description of a system determines the way to “connect” 
simple components in order to create a complete system. In the StAC language 
the components are B [1] operations. B is a model-oriented formal notation. We 
use B instead of EJBs because we want the language to have a formal semantics. 

A system specification has two components, the StAC specification that de- 
scribes the execution order of the operations, and a B specification that describes 
the state of the system and also its basic operations. Since there are commer- 
cial tools available to support the development in B, the B specification can be 
animated and also proof obligations can be generated and proved. 

An operational semantics is defined for the StAC language and its integration 
with B is also formalised through an operational approach. 

In Section 2 we present informally the StAC language and specify in StAC an 
e-bookstore. In Section 3 we complete the example specification by describing 
the B operations. Section 4 describes the semantics of StAC, and in the last 
section, we discuss the integration of StAC with B. 

2 The StAC Language 

We can say informally that in StAC a system is specified as a process, and 
such a process will be decomposed into several sub-processes in a top-down 
approach. At the bottom level there will only be activities (each activity is a 
atomic computation) , so they can not be further decomposed. Formally a system 
is described by a set of equations of the form 

N = P, 

where A is a process identifier and P is an expression that can contain several 
process identifiers, including A, since the equations can have recursion. We have 
determined, for simplicity reasons, that the first equation describes the overall 
system being specified. 

The distinctive characteristic about the StAC language is the concept of 
compensation. This concept can have many interpretations, the most common 
being recovering from an error. Each process can have a corresponding compen- 
sation process, so executing a process has two consequences: the execution of the 
process itself, and its compensation process must be preserved by the system^. 

Next we present two informal definitions of the concepts of compensation 
process and compensate. Later on these two concepts will be formally defined. 

Definition 1 (Compensation Process). Process representing activities to he 
performed to compensate some behaviour. 



Definition 2 (Compensate). Action of invoking the compensation process. 

^ Later on we will define what the expression “preserved by the system” exactly means. 
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The St AC language has some usual process combinators, like sequence and 
parallel. Besides these it has specific combinators to deal with the compensation. 
Next we present the syntax of StAC terms in Backus-Naur form: 



A 


(activity label) 


0 


(skip) 


b^ P 


(condition) 


rec{N) 


(recursion) 


P;Q 


(sequence) 


P\\Q 


(parallel) 


II x^X.Px 


(generalised parallel) 


P[]Q 


(choice) 


[jxCX.Pa; 


(generalised choice) 


P^Q 


(compensation pair) 




(compensate) 


□ 


(commit) 


[P] 


(compensation scoping) 



Each activity label A has an associated activity —>■ representing an atomic change 

A 

in the state: if U is the set of all possible states, then — >■ is a relation on A. In 
Section 3, we show how the B notation is used to describe state and activities. 
In the rest of paper we consider the capital letters A to D are activities, and the 
letters P and Q are processes. 

In the conditional operator, process P is guarded by a boolean function b. 
This boolean function can consult the state, i.e., 6 : A — >■ Bool and b ^ P is 
enabled only if b is true. The recursive operator rec{N) enables the use of a 
process identifier N of the right-side of an equation to be used in the left-side 
term of an equation. The sequence P; Q forces an order in the execution of P 
and Q: P must be executed first and only when P finishes can Q be executed. In 
parallel process P || Q, the execution of the activities of P and Q is interleaved. 
Generalised parallel extends the parallel operator over a set X, which can either 
be finite or infinite. The choice P[]Q selects whichever of P or Q is enabled. 
If both P and Q are enabled, the choice is made by the environment. Notice 
that the [] operator causes non-determinism in some cases. If we consider the 
following example: 

(A;P) D {A;C) 

when activity A occurs its not possible to determine which one of the two be- 
haviours A; B or A; C will be chosen. In this case, the choice is made by the 
system rather than the environment. Generalised choice extends choice over a 
set of processes. 

The next set of operators is related to the compensation concept. The com- 
pensation pair P A Q expresses that P has Q as its compensation process. The 
compensation process is constructed in the reverse order of process execution, 
for example: 






( 1 ) 



64 



M. Butler and C. Ferreira 



behaves as A; B and has the compensation process B'; A' . A compensation pro- 
cess can be viewed as a stack where processes are pushed into the top of the 
stack. 

The compensate operator K causes the compensation process to be executed. 
Consider the process (1) followed by 

{A^A'y,{B^B'y,m. ( 2 ) 

As we saw before, process (1) behaves as A; B, and then K operator causes the 
compensation process to be executed, so the overall behaviour of process (2) is 
(A; B)-, {B'\ A') which we write as A\B\ B'-, A' . 

The commit operator □ clears the compensation process, meaning that after 
a commit the compensation process is set to 0. Consider again process (1). If 
now we append to it the □ operator we have: 

[A^A'yiB^B'yui. 

As we already saw the compensation process of process (1) is B'\ A' , but after 
the □ operator the compensation process is 0. Another example, 

{A^A'y{B^B'yB;M 

behaves as A; B because when the Kl operator is called the compensation process 
B'\ A' has already been cleared by the □ operator. 

As we mentioned before the complexity of StAC language arises from the 
combination of compensation with parallel execution. Given the following par- 
allel processes: 



(A -A') II {B^B') 

the execution of processes A -F A' and B ^ B' is interleaved, implying that 
the execution of their compensation process should also be interleaved, so the 
resulting compensation process is A' || B' . 

Next we will consider the combination of compensation with choice. The 
process: 



{A^A')[]{B^B') 

behaves as A or i? and the compensation process in the first case is A' and in 
the second case is B' . 

The compensation scoping operator [P] creates a new compensation process 
within the square brackets. In the following process: 

(A-A');[(P^P')], 

the compensation process within the brackets is just B' , and A' is excluded 
because its outside the brackets. If we added the compensate operator as follows: 



{A^A'y[{B^B'ymy 
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the overall process would behave as A; B] B' , since the Kl just executes the com- 
pensation process within the brackets. Also, the process: 

{A^A'y,[{B^B');a];{C^C') 

has C] A' as compensation. Since the commit operator is inside the brackets, it 
just clears the compensation process B' that is within the brackets. Another fea- 
ture of the compensation scoping operator is that compensation is remembered 
if compensate is not performed, as in the example: 

{A^A');[{B^B')];{C^C'). 

Here, the compensation process is C"; B'; A', which includes the compensation 
process B' defined inside the brackets. B' is retained because there is no commit 
with the brackets. 

The StAC language permits nested compensation pairs as in the next exam- 
ple: 



A-(H-C). (3) 

The process (3) behaves as A and has the compensation process B ^ C. Lets 
review what happens when the compensate operator is appended to process (3), 

{A^{B^C))-m. (4) 

First A is executed, after the Kl operator invokes the compensation process B^C, 
so the behaviour of process (4) is A; B with compensation process C. 



Example: E-Bookstore 

The E-Bookstore is a typical example of an e-business. In this example each 
client defines a limited budget and has an e-basket where the selected books 
are kept. Every time the client selects a book, the budget is checked to see if it 
was exceeded, in this case the book is returned to the e-shelf. When the client 
finishes shopping he can either pay or abandon the bookstore, in the later case 
all selected books have to be returned to the shelf. Next, we present the StAC 
specification of the e-bookstore: 



Bookstore = || cec .Client {c) 

Client{c) = Arrive(c); ChooseBooks{c)\ ((Quit(c); Kl) [] Pay{c))\ □; Exit(c) 

ChooseBooks(c) = Checkout(c) [] (ChooseBook{c); ChooseBooks{c)) 
ChooseBookic) = []6gs.[(AddBook(c, b)^ReturnBook(c, 6)); overBudget(c) — 
Pay(c) = ProcessCard(c); -'accepted(c) — ^ Kl 

Notice that some processes are written with a different font, e.g., AddBook, 
this means that those processes are activity labels, and as mentioned before they 
can not be further decomposed. Activities will be specified as B operations in 



66 



M. Butler and C. Ferreira 



the next section. Both overBudget(c) and accepted(c) are boolean expressions 
which will also be defined in B. 

In the above specification the bookstore is represented by a infinite set of par- 
allel Client processes each indexed from a set C. This implies that the process 
Bookstore never ends, so it is always available and if a client exits the book- 
store he can later return with a new Client process. Each Client has a thread 
of compensation independent from all the other Client parallel processes. Also, 
each Client is a sequence of five processes. The first one is Arrive that creates 
and initialises the client information, setting the budget to a value determined 
by the client. The next process is ChooseBooks, followed by a choice between 
paying the books in the basket or abandon the bookstore without buying any 
books. If the client chooses to quit, the process Kl is invoked causing the return 
of all books in the client’s basket to the shelf. The fourth process is □ which 
discharges all compensation information. The last process is Exit that removes 
the client from the bookstore, clearing all the information related to that cli- 
ent. The process ChooseBooks is a recursive process where the client chooses 
between selecting individual books (process ChooseBook) and returning after- 
wards to ChooseBooks process or stop selecting books, choosing Checkout(c). 
ChooseBook creates a new thread of compensation, using scoping brackets. This 
new thread is only related to one book. Within ChooseBook there is a compen- 
sation pair, AddBook compensated by ReturnBook, and the compensation is 
executed only if adding that book to the basket exceeds the budget. In this case 
executing the compensation implies returning the book that has just been added 
to the basket rather than all books in the basket. In the process Pay, the clients 
card is processed, and if the card is rejected, the compensation is executed, so 
all selected books are returned to the shelf. 



3 Describing Activities in B 

B AMN is a model-oriented formal notation and is part of the B-method develo- 
ped by Abrial [1]. In the B-method, a system is defined as an abstract machine 
consisting of some state and some operations acting on the state. 



MACHINE Bookstore 
VARIABLES v 
INVARIANT I 
OPERATIONS 

END 



Fig. 1. Bookstore abstract machine 



A Process Compensation Language 



67 



The bookstore abstract machine has the structure outlined in Figure 1. 
The abstract machine consists of some variables which are described using set- 
theoretic constructs. The invariant is a set of first-order predicates. Operations 
act on the variables while preserving the invariant and can have input and output 
parameters. Initialisation and operations are written in the generalised substitu- 
tion notation of B AMN which includes constructs such as assignment, guarded 
statements and unbounded choice. 

Machine State 

Next we describe the machine state of our example, which is defined by the 
aggregation of the clauses VARIABLES and INVARIANT: 

MACHINE Bookstore 

VARIABLES budget, basket, price, accepted 
INVARIANT 

budget G C — ?► N A 
basket G C — >■ F(R) A 
price G R — >■ Ni 
accepted G C — ^ BOOL A 

END 

The clause VARIABLES names the variables of the abstract machine such as 
budget, basket, price and accepted. In the INVARIANT part we specify the 
types of the variables introduced in the previous clause. The variable budget is 
a function that for each client returns the maximum amount of money the client 
intends to spend in the bookstore. Variable basket is also a function but in this 
case it returns the books selected by each client. The price function contains 
the price of each book, which is necessary in order to verify if a client has exceed 
his budget. The variable accepted is a function that for each client determines 
if the client’s card was accepted or rejected. 

Machiue Operatious 

The operations defined in the B specification are the activities of the pro- 
cess Bookstore described in Section 2. The activities are Arrive, Checkout, 
AddBook, ReturuBook, Quit, ProcessCard and Exit. 

We will describe in detail some operations, the first one is the operation 

AddBook, 

AddBook(c, b) = SELECT ceC A be B A basket{c) THEN 
basket{c) := basket{c) U {6} 

END 

The SELECT construct enables the operation only if all conditions are true. In 
this case c must be in the set C of clients, b must be a book of the set B, and also 
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the book b must not be already in the basket of the client. The last condition 
was just added for simplicity reasons, we could extend the basket variable to 
return a bag instead a set of books. If all conditions are met, book b is added 
to the basket of client c. The operations ReturnBook, Arrive and Exit are 
similar to the operation described above in the sense that they are enabled by 
certain conditions and all of them cause a change in the machine state. 

Next we describe the operation Checkout: 

Checkout (c) = SELECT c G C THEN skip END 

This operation is enabled if client c is in the set C. Since Checkout is used in 
the StAC process Bookstore to exit the recursive definition of ChooseBooks, 
this operation does not need to perform any explicit action. Operation Quit is 
similar to operation Checkout, and is used to determine which action the client 
wants to perform, quit the bookstore or pay the books. 

The boolean function overBudget is specified as a B definition, since it only 
consults the machine state: 

overBudget(c) '^= budget{c) > {b G basket(c) | price(6)) 

This boolean expression calculates if the total price of the books in the client’s 
basket exceeds the initial budget. 

Operation ProcessCard sets the variable accepted. The variable accepted 
is used in the process Pay to trigger the compensation process when the card is 
rejected. 

ProcessCard(c) = SELECT c G C THEN 

CHOICE accepted := TRUE OR accepted := FALSE 
END 

Operation ProcessCard is described as a choice between attributing the value 
TRUE or FALSE to the variable accepted depending on the card being ac- 
cepted or rejected. The need for this variable is due to the fact that conditional 
processes must only use boolean expressions as guards, and ProcessCard is not 
a boolean function, because for the same state it can assign different values to 
variable accepted. 

We can state that any guards of conditional processes should be specified in 
B as boolean expressions of the variables of the state machine. 

4 The StACj Language 

In this section we introduce the StAC^ (Structured Activity Compensation with 
indexes) language which extends the StAC language by adding different threads 
of compensation to a process. The main reasons for creating this new language 
is that StACi has a clear semantics for compensation and makes it easier to 
describe parallel compensation. 
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We define formally the syntax and the semantics of StAC^ language. This 
new language will be used to define the semantics of StAC. To achieve that we 
constructed a translation function from StAC to StACi terms. 

The main purpose in defining the operational semantics was the formalisa- 
tion of the concepts present in the StAC language, which was the aim of the 
collaboration with IBM. Also, we will justify (section 5) the integration of StAC 
and B through an operational approach. 

4.1 Abstract Syntax 

The StACi language extends the concept of compensation present in StAC lan- 
guage. In StACi a process can have several compensation threads, each one with 
an independent compensation process. The new operators reflect the extension 
of the StAC language. Operator P^iQ denotes that Q is the compensation pro- 
cess of P within the thread i. In same way operators and Hi compensate and 
commit, not the general compensation process, but the compensation process of 
the thread i. The new operator J O i merges all compensation processes of the 
threads belonging to J into the compensation process of thread i. 

A process in the StAC^ language is defined by the following Backus-Naur 
form: 



Process ::: 



= A 


(activity label) 


1 0 


(skip) 


\b^ P 


(condition) 


rec{N) 


(recursion) 


1 P;Q 


(sequence) 


\P\\Q 


(parallel) 


1 II x^X.Px 


(generalised parallel) 


\P[]Q 


(choice) 


1 []a:eX.Pa; 


(generalised choice) 


\P^^Q 


(compensation pair) 


1 


(compensate) 


1 


(commit) 


\ J \> k 


(merge) 


and StAC, 


languages are very similar, StACi has 



some additional symbols i, k, J and [>. Symbols i and k are are members of the 
set of indexes I, also J is a subset of /. J O fc is a new operator and it will be 
described formally in the next section. 



4.2 Operational Semantics 

The semantic domain of an StACi program is a tuple, 

(P, C, a) G Process x (/ — :► Process) x E 
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which we call a C on figuration. In the above tuple, C is the set of compensa- 
tion threads for the process P, such that for each index z, C{i) represents the 
compensation process of thread i. E represents the state of the B machine. We 
will write a labelled transition 

(P, C, a) 4 (P', C', a') 

to denote that executing activity A may cause a configuration transition from 
(P, C, a) to (P', C, a'). 

In any configuration, the choice between enabled transitions with different 
labels is made by the environment while the choice between enabled transitions 
with the same label is made by the system. 

Some rules of the operation semantics are silent rules, where the transition 
is not labeled. Those rules do not introduce non-determinism because their ap- 
plicability is disjoint from the rules for labelled transitions and from each other. 

Next we give a set of operational rules for StACi programs. 



Activity 

We assume that an activity is a relation from states to states, and write ct 4 ct' 
when a is related to cr' by 4. The execution of an activity within an StAC^ 
process imposes a change in the state, leaving the compensation function un- 
changed: 

cr 4 tr' 

(A, C, a) 4 (0, C, a') 



Condition 

In this case the execution of a process P is guarded by a boolean function b. If 
the result of applying b to the current state is true, then P may be executed: 

(P, C, a) 4 (P', C , a') A 6(cr) = true 
{b ^ P, C, a) 4 (P', C", aO 

If the result of b is false then 6 — >■ P is replaced by skip and both the compensation 
function and the state remain unchanged: 

b{a) = false 

(6 P, C, cr) — >■ (0, C, cr) 



Recursion 

In the recursive call of a process N (TV is a process identifier), rec{N) is substi- 
tuted by the term of the left-side of the equation N = P: 

N = P 



{rec{N), C, cr) -)> (P, C, a) 
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Sequence 

This rule states that in a sequence of processes P; Q, an order is imposed, so the 
process P is executed first and only then Q can be executed: 

(P, C, g) 4 {P\ a, a') 

(P; Q, C, a) 4 (P'; Q, C', a') 

Executing 0 in sequence with P is the same as executing P alone: 



(0;P, C, a) ^ (P, C, a) 



Parallel 

Parallel processes can be executed in an arbitrary order: 

(P, C, g) 4 (P', C', gQ (P, C, a) 4 (P', aQ 

(P II Q, C, a) 4 (P' II Q, C, a') {Q || P, C, a) 4 {Q || P', C', a') 

Executing a process P in parallel with 0 is equivalent to just executing P: 



(P II 0, C, a) ^ (P, C, a) (0 || P, C, a) ^ (P, C, a) 

Note that the parallel process P || Q terminates (i.e., reduces to 0) when both 
P and Q terminate. 

Generalised Parallel 

The rules for parallel are generalised for set X: 

{Pxi, C, O') — >■ {PxiJ C", a') A xi € X 
(II x^x.Px, C, a) 4 ((II xe(x-{x^}).Px) II P^^, C', a') 



Choice 

In the process P[]Q only one of the processes P or Q is executed: 

(P, C, a) 4 (P', C', a') (P, C, g) 4 (P', C', gQ 

(P[]Q, C, a) 4 (P', C\ a') {Q[]P, C, a) 4 (P', C', a') 

The choice between process 0 and any other process P is equivalent to the single 
process P: 



(P[]0, C, a) ^ (P, C, a) (0[]P, C, a) ^ (P, C, a) 
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Generalised Choice 

This operator extends choice over a set X : 

C, g) 4 (P'^, C', a') A Xi ex 
C, a) 4 (P'^, C', a') 



Compensation Pair 

In the compensation pair P^Q, an evolution in process P does not alter process 

Q: 



{P, C, a) 4 (P', a, a') 

(P Q, C, a) 4 (P' Q, C', a') 

The rule below adds the compensation process Q to the compensation function 
C, which only happens when the process P finishes: 



(0 -Fi Q, C, a) — >■ (0, C[i Q\ C'(z)], a) 

The notation C\i := P] denotes that the compensation process of the thread 
i is set to P. In the above rule the expression C[i := Q;C(i)] means that the 
compensation thread i is set to Q in sequence with the previous compensation 
process of i, implying the order of the compensation process is the reverse of the 
order of execution of the processes. 



Compensate 

In the next rule, the operator causes the compensation process of level i to 
be executed, and also resets that compensation process to 0: 



C, a) ^ (C(z), C[i := 0], a) 



Commit 

The operator 0^ clears the compensation process of level i to skip: 



(□*, C, a) -)■ (0, C[i := 0], cr) 



Merge 

The operator J t>i merges all compensation processes threads of set J in parallel 
on to the front of compensation process of thread i: 



(Jl>i,C,a) ^ (0, C[z:=(||,6J.C(j));C(*),J:=0], a) 

In the above rule the expression J := 0 denotes attributing to all elements of set 
J the process 0, i.e., {j := 0 | j £ J}. J must be disjoint from i. 
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4.3 Translation from StAC to StAC^ 

Instead of defining the semantics of the StAC language, we define a translation 
from StAC to StAC^, so the interpretation of an StAC process P is given in 
terms of StACi by the translation function. 

Next we present function T that translates an StAC process into an StAC^ 
process, 

T : L(StAC) X / ^ L(StAC,) 

where L(StAC) and L(StACi) represent StAC and StAC^ languages, and / is 
a infinite set of indexes. The parameter I is necessary in order to define T 
recursively. To translate a process P we have to select an index i G I, and then 
T{P,i) will return a StAC^ process. 

The next translation rules are fairly simple. For example, to translate a se- 
quential process P; Q with an index i is necessary to translate each process P 
and Q with the same index i: 

T{A,i) =A 

r(b^p,i) =b^r(p,i) 

T(rec(P),i) =rec(T(P,i)) 

T(P;Q,t) =T(P,i);T(Q,i) 

r(p[]Qc) =r(p,^)l]r(Q,^) 

T([]xgx.Pj,, ) = l]xex.T(PxA) 

T(P^Q,i) =P^^Q 

r(□,^) =□. 

T(0,i) =0 

The following set of rules are more complex. The main difficulty in the trans- 
lation is parallel processes and their compensation information. Since we do not 
know the order of execution of P || Q it implies that we also do not know in 
which order their compensation should be executed. The solution is to create 
a new thread for each parallel process, so their compensation process is also 
a parallel process. In the end both new threads, j and fc, are merged into the 
previous thread i. 

T{P II Q, i) = □{,, fej; (T(P, j) II T(g, k))- {j, k} \> i 

T(|| xGX.Pa,,z) = 0j; (II x(^X.T{Px,jx))] J > * 

where j and k are new distinct indexes, and J = {jx | a; £ A} is a set of 
new indexes such that x ^ x' ^ jx ^ jx' - The notation is a simplification 
for II The final merge means that the compensation processes of the 

parallel processes are retained (unless they have been explicitly committed). 

In the last rule we translate the compensation scoping [P]. The scoping 
brackets are translated to a new thread of compensation that in the end is 
merged in to the previous index: 

r([P],z) = 0,;r(P,j);{j}>* 
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where j is a new index. 

To clarify the translation described above, we will exemplify the translation 
of a simple process, 

T{A^A' \\ B^B');C^C',i) 

= T{A ^A'\\B^ B', i); T{C 4- C , i) 

= {T{A ^A',j)\\T{B^B',k))- {j, k}>i-C C 

= H{j,fc}; {A A' II B 4-fc B')] {j, k}>i;C 4-i C" 

The first rule applies the function T to both sequential processes A-hA' || B^B' 
and C-fC". To translate the parallel process it is necessary to create a new thread 
for each parallel process. After the translation of both parallel processes, the new 
threads are merged into the initial thread. 



5 Integrating StAC* and B 

The operational semantics rules at Section 5 allow us to consider a process as 
a Labelled Transition System (LTS) as in [6]. Furthermore, [2] shows how a 
B machine can be viewed as an LTS. For those reasons, the semantics of the 
integration of StAC^ and B will be defined based on the operational semantics. 

A B machine can be viewed as an LTS, where the state space is represented 
by the cartesian product of the types of state of the machine variables, labels 
are represented by the operations names and the transitions are represented by 
the operations. 

The semantics of B operations is given in terms of weakest preconditions. For 
a statement S and postcondition Q, [S']<5 represents the weakest precondition 
under which S is guaranteed to terminate in a state satisfying Q. 

In order to define when a transition is allowed by a B operation, we use the 
notion of conjugate weakest precondition defined as follows: 

{S)Q = -|5]-Q. 

{S)Q represents the weakest precondition under which it is possible for S to 
establish Q (as opposed to the guarantee offered by [S'JQ). Rules for [S'] and (S) 
are shown in figure 2. 

Suppose the B machine represents activity A with an operation of the form 

A = S, 

where A is the operation identifier and S is a B AMN statement on the machine 
state a, then the transition 



is possible provided 



V 



a ^ {S){v = a'). 
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[a: := E]Q 

[CHOICE S OR T END\Q 
[SELECT P THEN S END] 



substitute E for a; in Q 
[5]Q A [T]Q 
p ^ [5]g 



{x := E) 
{CHOICE S 
{SELECT P 



OR T END)Q ={S)Q\/{T)Q 
THEN S END) = P A {S)Q 



= [x := E] 



Fig. 2. [S] and {S) rules 



Here v represents the variables of the state machine. 
A parameterised B operation of the form 

A{x) = S 



represents a set of activity definitions with labels of the form A.f, and the ope- 
ration corresponding to activity A.i is given by the statement x := i] S. 

6 Conclusions 

The aim of the collaboration with IBM was to formalise the concepts of the 
strnctnred ordering of activities and activity compensation. We have achieved 
that by defining a langnage (StACi) that specifies a system as a set of process 
eqnations. The langnage permits choice, parallel and seqnential behavionrs. Bnt 
most important, StAC^ formalises the concept of compensation. Each process 
can have a compensation process, that is invoked when its actions need to be 
compensated. There are special processes called activities that represent atomic 
computations. Instead of extending StACi to inclnde variables and expressions 
we nsed the B notation to specify activities. The specification of a system has 
two components, a set of process eqnations and a B machine describing the 
activities. The B machine inclndes a state, operations on the state and boolean 
expressions. The semantics of the StAC^ langnage and its integration with B is 
jnstified throngh an operational semantics. 

The work presented in [3] has similar aims, bnt it does not have the concept 
of compensation. 

Fntnre work inclndes the translation of St AC processes into a B machine. 
Having the overall system specified in B wonld allow the specification to be 
animated and appropriate proof obligations to be generated (which is already 
possible for the activities). An experimental translation has been devised, bnt 
it is necessary to provide a formal proof that the translated specification is 
eqnivalent to the combined StAC^ and B specification. 

Another important extension to the present work is to snpport the refinement 
of the B machine, that specifies the overall system, to compositions of EJBs. 
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This would guarantee the correctness of all of the development steps, from the 
abstract specification (StACi and B) to the implementation (Java code). 

Acknowledgments. We would like to thank Peter Henderson of DSSE and 
Iain Houston, Mandy Chessell, David Vines and Catherine Griffin of IBM UK 
Labs for their contribution. 
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Abstract. The widespread adoption of graphical notations for software 
design has created a demand for formally-based methods to support and 
extend their use. A principal focus for this demand is the Unified Mo- 
deling Language (UML), and, within UML, the diagrammatic notations 
for describing dynamic properties. 

This paper shows how one such notation, that of Activity Graphs, can 
be given a process semantics in the language of Communicating Sequen- 
tial Processes (CSP). Such a semantics can be used to demonstrate the 
consistency of an object model and to provide a link to other methods 
and tools. A small example is included. 



1 Introduction 

The Unified Modeling Language (UML) [22] is a collection of graphical notations, 
each of which can be used to specify different aspects of structure, state or system 
behaviour at varying levels of rigour and abstraction. It has been widely adopted 
for object-oriented software development. UML has an extensively-documented 
structural semantics but, as [8] observe, lacks any formal static or behavioural 
semantics. 

A significant amount of work has been done on the formal semantics of UML, 
notably: a type semantics of class models [11]; dynamic semantics for state dia- 
grams [14] and state machines [4]; and the combined work of the precise UML 
group [19]. Closely related to our work is that of [16] and [1]. In addition, some 
of the notations, being adapted from existing methods, have inherited a formal 
semantics by association. Activity graphs, diagrams used to describe the flow of 
behaviour within a system, are an example of this inheritance. They combine 
features of State Charts [12] with the intuition of Petri Nets. 

The contribution of this paper is two- fold. Firstly we provide a formal se- 
mantics for activity graphs, describing them in terms of the process language 
CSP [13]. Secondly, based on results presented in [11] and a refinement-preserving 
translation from abstract data types to processes described in [3], and along si- 
milar lines to the work of [9] and [5], we describe how the final class description 
of a system can be expressed as an abstract data type and then translated to its 
corresponding CSP process. 
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Using refinement we can then compare the process corresponding to a class 
description against processes corresponding to activity graphs constructed in its 
development process; we can verify that the final class description is consistent 
with its specification. 

An earlier attempt at formalising the semantics of activity graphs, by the 
current authors, is included in [2]. The intent there was quite different: to de- 
monstrate that a uniform process semantics could be used to check the consi- 
stency of different parts of a process model. The treatment of activity graphs, 
in particular, was rather more superficial than that described here. Two notable 
differences are that the graph transitions in [2] could not be labelled with actions 
and events and that the semantics only applied to graphs with a restricted topo- 
logy. For instance, the semantics of [2] could not cope with cross-synchronisation, 
as illustrated in Figure 1. 




Fig. 1. An activity graph with cross-synchronisation. 



In this paper, we take an entirely different approach to the graph notation: 
states, pseudo-states and transitions are all now modelled in terms of processes. 
Furthermore, the graph syntax of [2] has been discarded and replaced with one 
much closer to the de facto standard of the Rose interchange format [20] . 

The paper begins with a brief introduction to the mathematical notations 
used throughout the document. In Section 3, we introduce the graphical nota- 
tion used in activity graphs and our corresponding syntactic definitions before 
presenting our behavioural semantics in Section 4. In Section 5, we give an ex- 
ample of a simple class description and an activity graph that might have been 
constructed during its development process. We show how our behavioural se- 
mantics may be used to verify that they are consistent. We conclude the paper 
with a discussion on the applicability of this work and highlight potential areas 
for future research. 
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2 Notation 

The mathematical notation used in this paper is a combination of Z [24], CSP [13] 
and Object-Z [7,23]. In Section 6 we assume a little knowledge of Petri nets (see, 
for example, [18]). 

2.1 Z and Object-Z 

The language of Z is widely used for state-based specification. A characteristic 
feature is the schema, a pattern of declaration and constraint. The name of a 
schema can be used anywhere that a declaration, constraint or set could appear. 
Schemas may be named using the following syntax: 

Name 

declaration 

constraint 



If 5 is a schema, then 9S denotes the characteristic binding of S in which 
each declared component is associated with its current value. This semantics 
supports the definition of a schema calculus, in which specification and analysis 
can be conducted at the level of schemas, abstracting and encapsulating the 
components declared within them; we can refer to the collection of identifiers in 
a particular schema without introducing a named instance of that schema type. 

Schemas can be used as declarations. For example, the expression XS • t 
denotes a function from the schema type underlying S, a set of bindings, to the 
type of term expression t. 

The Z notation has a standard syntax for set expressions, predicates and 
definitions. Basic types, maximal sets within the specification, may be introduced 
as follows. 

[Type] 

Using the axiomatic definition we may introduce a global constant z, drawn 
from a set S, satisfying predicate p. 

X : S 
P 

Object-Z is an object-oriented extension of Z adding notions of classes, ob- 
jects, inheritance and polymorphism. A class is represented by a named box 
containing local types, constant definitions and schemas describing state, initia- 
lisation and methods on the class. 

Class Name[generic parameters] 

local type and constant definitions 
state schema 
initial state schema 
operations 



80 



C. Bolton and J. Davies 



2.2 Processes 

A process, as defined in [13] , is a pattern of communication. We may use processes 
to represent components in terms of their communicating behaviour, building 
up descriptions using the standard operators of the CSP language. 

Processes themselves are defined in terms of events: synchronous, atomic 
communications between a process and its environment. Compound events may 
be constructed using ‘ . ’ the dot operator; a family of compound events is cal- 
led a channel, and may be used to represent the passing of a value between 
components. 

Processes may be defined by sets of mutually-recursive equations, that may be 
indexed to allow parameterised definitions. Parameters may be used to represent 
aspects of the process state, and may appear in guards', we write B &z P to denote 
the process that behaves as P if i? is true, and can perform no events otherwise. 

The atomic process Skip denotes successful termination, the end of a pattern 
of communication. If P is a process and a is an event then a — >■ P is a process 
that is initially ready to engage in a. If this event occurs then the subsequent 
behaviour is that of P. If P and Q are both processes, then the process P 1 Q 
first behaves as P and then, if P terminates, behaves as Q. 

If P and Q are processes, then P r\ Q represents an internal choice between P 
and Q'. this choice is resolved by the process without reference to its environment. 
An internal choice over a set of indexed processes {i : I • P(*)} is written 
VM : I • P{i). An external choice between two processes, written P □ Q, may be 
influenced by the environment; the choice is resolved by the first event to occur. 
An external choice over a set of indexed processes is written □ i : I • P(i); 
if each begins with a different event, then this is a menu of processes for the 
environment to choose from. 

We write || z : / • [A(z)] P(z) to denote an indexed parallel combination of 
processes in which each process P(z) can evolve independently but must synchro- 
nise upon every event from the set A(i). The combination may terminate only 
when every process is ready to do so. In an interleaving parallel combination, no 
synchronisation is required; in the combination P |j| Q, the two processes evolve 
independently. We also employ an indexed version of the operator: ||| z : / • P(z). 
As with ordinary parallel combination, termination requires the agreement of all 
parties. Processes may also be partially-interleaved, in the sense that they must 
synchronise upon certain events but may perform other common events inde- 
pendently. In the combination P |[ A ]| Q, the two processes must synchronise 
upon every event from the set A, but may perform all others independently. 

Finally, if P is a process and A is a set of events then P \ A is a process 
that behaves as P, except that both the requirement to synchronise upon and 
the ability to observe events from the set A has been removed. 

2.3 Behavioural Semantics of Processes 

Several standard semantic models exist for the process language of CSP: see, for 
example, [21]. For the purposes of this paper we will employ the traces model; 
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it may be inappropriate to infer precise availability information from an activity 
graph. In this model, each process is associated with a set of traces, or finite 
sequences of events. The presence of a trace in the semantic set of a process 
indicates that it is possible for that process to engage in that sequence of events. 

Letting S denote the set of all event names and CSP denote the syntactic 
domain of process terms, we may define the semantic function T that takes a 
CSP process and returns the set of all traces of the given process. 

r : CSP ^ P(seqr) 

The traces model admits a refinement ordering based upon reverse contain- 
ment. 



_ Gr - : CSP O CSP 

VP, Q:CSP»PnrQ^ T{Q) c T(P) 

Refinement may be established through a combination of structural induction [6] , 
data-independence [15], and exhaustive, mechanical model-checking as described 
in [21]. 



3 Graphical and Syntactic Descriptions of Activity 
Graphs 

An activity graph is a special type of state diagram that is used to model the 
flow of activities within a procedure; essentially it describes a collection of use 
cases. An activity graph is constructed from a combination of action states, 
(sub)activity states, start and finish states and pseudostates merge, decision, 
fork and join. A table showing the graphical representation of each type of state 
is presented in Figure 2. 

Syntactically we define these states as follows: 

Type ::= action {(Action)) \ activity {{Activity Label)) \ 

start I finish \ merge \ deeision \ fork \ join 

where Action and ActivityLabel are given types. 

[Aetion, Aetivity Label] 

Note that activity states and action states although graphically indistinguis- 
hable, as illustrated in Figure 2, are very different semantically. An action may 
be thought of as a simple task that cannot be broken down any further, whereas 
an activity is a task that can be broken down, and may itself be expressed as 
an activity graph. An ActivityLabel within an activity state points to another 
activity graph within the specification; an example of an activity state is “Build 
House” within the “Create House” activity graph illustrated in Figure 3. 

The states within an activity graph are linked together by transition lines. 
These lines may have associated guards and actions as illustrated in Figure 4. 
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action 


activity 


start 


finish 


.1 








• 




C J 


C 3 


1 










Fig. 2. States of an activity graph. 



Create House 





Fig. 3. A graph nested within a graph. 

[ guard ] action 

> > > 

Fig. 4. A simple transition, a guarded transition, and a transition enabled by an action. 



Given the types Line and Guards 
[Line, Guard] 



the schema definition of a transition is as follows: 
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Transition 

guard : Guard 
action : Action 
line : Line 



If the graphical representation shows no guard or no action then the schema 
description of the transition records the default values true and null respectively. 

true : Guard 
null : Action 

Each state within an activity graph records the type of its contents, the set 
of incoming lines it requires and the set of outgoing transitions it enables. 

State 

lines : P Line 
transitions : P Transition 
type : Type 



The type State allows all possible states, including those which are not permis- 
sible within a UML specification. The schema WellFormed describes the subset 
of possible states that are permissible according to the constraints within the 
official documentation [17]. 

WellFnrm.edStn.te 

State 

type = start lines = 0 

type = finish ^ transitions = 0 

type € {start, merge, join} ff transitions = 1 

type € [finish, decision, fork} ff lines = 1 

{3tr : transitions • tr.line € lines ) 

=> type ^ [start, finish, merge, decision, fork, join} 



An activity graph is built up from a finite set of well- formed states. The 
environment of a specification is a function mapping the name of each graph to 
the associated graph. These are described formally below. 

Graph ::= states {{¥ WellFormedState)) 

Env == ActivityLabel -P- Graph 

4 Behavioural and Semantic Descriptions 

In this section we define our semantic function which takes the name of an ac- 
tivity graph within a specification and returns the CSP process that models the 
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behaviour of that graph. Essentially, this function returns the parallel combina- 
tion of the processes corresponding to the states within the named graph each 
synchronising on its own alphabet; the synchronisation of the line events ensures 
that the actions occur in the correct order. 

We introduce the types Process and Event 
[Process^ Event] 

and define the functions eum and e action which, respectively, map line names and 
actions to events. We insist that events corresponding to each line and to each 
action are distinct. Having defined an Action to be a simple task that cannot be 
broken down any further we may justifiably model it as a single event. 



Eiine ■ Line m-> Event 
^action ■ Action Event 



ran£^ 2 ne Tixm £ action — 0 



4.1 Alphabets 



In order to define the alphabet for each state — the events on which it must 
synchronise — we must consider the events associated with each line, type and 
transition. We introduce functions aune, cttran, cttype and a state which respec- 
tively take a line, a transition, the type of a state, and a state and return the 
associated set of events. 

The set of events associated with a line is simply the relational image of 
the line under sune- The set of events associated with a transition is the set 
containing the events corresponding to its line and its action. 



aiine '■ Line -P- P Event 
cx-tran '■ Transition P Event 

aune = ( A line : Line • {sune line} ) 

outran = ( A Transition • { Sune line,£acUon action } ) 



The set of events associated with the type action state with given action actn 
is the set containing the singleton event corresponding to actn, whereas the set 
of events associated with the type activity state with given ActivityLabel actL is 
the alphabet of the graph corresponding to actL] this is simply the union of the 
alphabets of all the states in the identified graph. The set of events associated 
with all other types of state is simply the empty set. 
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o^type '■ Type -!->■ Env -!->■ ¥ Event 

V env : Env; type : Type; actn : Aetion; actL : ActivityLabel • 
type £ {start, finish, merge, deeision, fork, join} 



a type type env = 0 
A 

atype {action actn) env = {SacUon actn} 

A 

o:type {activity actL) env = U ( { state : State \ 

state £ states'^ {env actL) • 
astate state env } ) 

The alphabet of a given state is the union of the alphabets of all of its 
incoming lines, the alphabet of its type and the alphabets of all of its outgoing 
transitions. 

(Estate '■ State -£ Env -£ P Event 

e^state ( State • 

( A env : Env • ( IJ {aune d tines D) 

U 

U {outran d transitions D) 

U 

cttype type env))) 



4.2 Processes 

We observed at the beginning of Section 4 that the process corresponding to the 
behaviour of a named activity graph within its specification environment was 
simply the parallel combination of the processes corresponding to its constituent 
states, each synchronising on its own alphabet. All line events are then hidden. 
We formally define the function as follows. 

semantics : ActivityLabel -£ Env -£• Process 

V env : Env; actL : ActivityLabel • 
semantics actL env = 

(|| state : states^ {env actL) • [astate state env] Pstate state env) 
\ U ( ■ states'^ {env actL) • eune{ st.lines |)} ) 

The function Pstate returns the process corresponding to the behaviour of the 
given state, p state is essentially the sequential composition of the processes cor- 
responding to the lines, type and transitions of the given state. In order define 
it formally we must consider these constituent processes and the effect of loops 
on the system. 

The process that corresponds to the behaviour of the type action state with 
given action actn, is simply the event associated with actn followed by Skip, 
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whilst the process that corresponds to the behaviour of the type activity state 
with given ActionLabel actL, is the process corresponding to the graph associa- 
ted with actL. The process that corresponds to the behaviour of all other types 
of states is simply Skip. 

Ptype ■ State -!->■ Env Process 

^ state : State; env : Env; actn : Action; actL : ActivityLabel • 
state. type = action actn 

Ptype state env = (Saction actn) -)► Skip 
A 

state. type = activity actL 

Ptype state env = semantics (actL) env 
A 

state.type € {start., finish, merge, decision, fork, join} 

Ptype state env = Skip 

We observe that the difference between a merge state and a join state is that 
a merge state can be reached provided any one of its incoming lines is enabled 
whereas a join state can be reached only when all of its incoming lines have been 
enabled. In order to reflect these differences we define the following processes. 

Require Any {Is) = □ e : ejined Is ) • e ^ Skip 

Require All (Is) = ||| e : eune{ k |) • e — >• Skip 

Similarly, in order to reflect the difference between a fork state where all 
outgoing transitions are enabled and other states where only one transition may 
be chosen, we define the following processes. 

Eork{ts) = III Transition \ 9 Transition G ts • 

guard & ( if {action = null) then {eune line) — > Skip 
else 

{^action action) ->■ {eune Une) Skip ) ) 



Choice{ts) = □ Transition \ 9 Transition G ts • 

guard & ( if {action = null) then {eune line) — > Skip 
else 

{^action action) {eune Unc) Skip ) ) 

Observe that if there is no action event on the transition line, that is action = 
null, then the corresponding process has no action event. 

Given these definitions we define the function ptrans that takes a state and 
returns the process that corresponds to the behaviour of its outgoing transitions: 
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Ptrans '■ State -!->■ Process 

Ptrans ( '^ State • 

if {eomponent = finish) then Skip 
else 

if {component = fork) then Fork {transitions) 
else 

Choice {transitions) ) 

Note that we define the process corresponding to the transitions of a finish state 
to be Skip. This avoids having to choose one from an empty set of transitions 
that would give rise to deadlock. 

Before we define the function punes, consider the graph illustrated in Figure 5. 
Since Une2 is a self-transition, that is, it loops back directly to the same state. 



linel 



\ 


/ 


' A 

actn 







line2 



Fig. 5. An activity looping back to itself. 



the event eune Hne2 will not be in the alphabet of the process corresponding to 
any other state. This event will therefore not be constrained by synchronisation 
and can occur at any time. Thus, we must treat incoming lines which are part 
of a self-transition separately when considering the process corresponding to the 
incoming lines. We define the function loops to take a state and return the set of 
all self-transitions, and the function aioops to return the set of all lines contained 
in a self-transition. 

Oiioops '■ State -!->■ P Event 

loops : State -i-> P Transition 

loops = {X state : State • {tr : state .transitions \ tr.line £ state.lines}) 

Oiioops = ( X state : State • {tr : loops state • sune {tr.line)}) 

Given these definitions, and recalling that only action states and activity can 
have direct loops back to themselves in a well-formed graph, we define the func- 
tion piines which takes a state and returns the process describing the behaviour 
of all the incoming lines as follows. 

Piines ■ State -£ Process 

Piines — ( state . State ® 

if {type = join) then Require All {lines) 
else 

Require Any {lines \ {aioops state )) ) 

Finally, we define the function Pstate which takes a state within a given speci- 
fication environment and returns the process which models the behaviour of the 
entire state; the incoming lines, the type of state and the outgoing transitions. 
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Pstate '■ State -!->■ Env Process 

P state 

( A state : State • ( A env : Env • 

if {type = start) then ptrans state 
else 

if {ctioops state = 0) then 

let 

^ — Plines state g 

( Ptype state env Ptrans state 9 At 

within 

X 

else 

let 

y = PUnes state i III Y) 

Z = Ptype state env g 

( Choice {loops state) g Z 

□ 

Choice {transitions \ {loops state)) g Y ) 

within 

Observe that the process corresponding to a start state is the only non-recursive 
process; a start activity can occur only once. For all other states, through in- 
terleaving the process with itself after the events corresponding to the incoming 
lines have occurred, we enable the incoming lines events to occur many times be- 
fore the events corresponding to the state type and the state transitions occur^, 
thereby mirroring the intended behaviour of the graph and hence the system. 



5 Example 

In this section we present an Object-Z description of a simple ticket machine. 
We assume that this model was derived as the result of a UML specification and 
present an activity graph that might have been constructed in the development 
process. We show how both the Object-Z description and the activity graph 
can be translated to their process equivalents in CSP. We are then able to do a 
refinement check to determine whether or not the final model is consistent with 
the activity graph. 



^ This corresponds closely to Petri nets in which each place can contain multiple 
tokens. 
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5.1 Activity Graph Describing a Ticket Machine 

We assume that the activity graph illustrated in Figure 6 was constructed during 
the development process of a ticket machine (although we have added line names 
to our graph). We observe that a coin can be inserted at any time, and that for 




Fig. 6. An activity graph describing a simple ticket machine. 



each coin that has been inserted either the red button or the green button may 
be pressed. If the red button is pressed then a coin will be returned. If the green 
button is pressed then the machine will non-deterministically choose either to 
issue a ticket or to return a coin. 

We define the following set I which indexes the processes corresponding to 
the states within the graph. 

I = {start, insert, fork, choicel, choice2, return, issue, stopR, stopG} 

In addition, we identify the following sets of events corresponding to the actions 
and lines described in the graph. 

Actions = {insertCoin, pressRed, pressGreen, issueTicket, returnGoin} 

Lines = {Z : 1 . . 10 • lined} 

Our syntax corresponds closely to the Rational Rose interchange format [20] 
and we may therefore readily obtain our syntactical interpretation of the graph. 
Applying our semantic function to this syntactic description we obtain the pro- 
cess corresponding to the activity graph. 

GraphProcess = ( || i : / • [ A(i) ] P{i ) ) \ Lines 
where for each i in /, the process P{i) is as defined below: 

P(start) = line.l — >■ Skip 

P{insert) = (line.l — >• Skip □ Zme.4 — > Skip) g 

( insertGoin — >■ line.2 — >• P(insert) 



P(insert ) ) 
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P{fork) = line.2 — >■ ( ( line.3 — >■ Skip 1 1 1 lineA — >■ Skip ) g P{fork) 

P{fork ) ) 

P{choicel) = 

line.3 — >■ ( green — >■ line.b — ^ P{choicel) □ red — >■ line.9 — >■ P{choicel) 
P{choicel ) ) 

P{choice2) = line.5 ^ {line.6 ^ P{choice2) O line.8 ^ P{choice2) 

P{choice2 ) ) 

P{issue) = line.6 — >• ( issueTicket — >■ line.7 — ^ P{issue) 

P{issue ) ) 

P{stopG) = line.7 {Skip ||| P{stopG)) 

P{return) = (/me. 8 — ?► □ /me. 9 — >■ S'fcip) g 

( returnGoin — ^ /me. 10 — ^ P{return) 

P {return ) ) 

P{stopR) = line.7 — >■ ||| P{stopR)) 

and for each i in /, the set of events A{i) is as defined below: 

A{start) = {/me.l} 

A{insert) = {/ine.l, /me.2, /me.4, inser/Com} 

A{fork) = {/me. 2, /me. 3, /me. 4} 
j4(c/ioicel) = {line .3 , line .5 , line .9 , red , green} 

A{choice2) = {/me. 5, /me. 6, /me. 8} 

^(/sswe) = {line. 6, line. 7, issueTicket} 

A{stopG) = {line.7} 

A{return) = {line. 8^ line. 9, line. returnGoin} 

A{stopR) = {/me. 10}. 

5.2 Object-Z Description of a Ticket Machine 

In this section we give an Object-Z description of a ticket machine which might 
have been constructed based on a UML specification containing the activity 
graph illustrated in Figure 6. 

Four state variables have been introduced during the development process: 
coins is the number of coins that have been inserted for which the user has 
not yet selected the red button or the green button; tickets is the number of 
tickets left in the machine; to Return is the number of coins to be returned; and 
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tolssue is the number of tickets to be issued. Note that the non-determinism in 
the activity graph — the machine could either return a coin or issue a ticket if 
the green button was pressed — has been resolved. In the Object-Z description, 
if the green button is pressed then the machine will issue a ticket if there is one 
left; otherwise it will return a coin. 



TicketVendingMachine 



Init . 



coins, tickets : N 
to Return, tolssue : N 


coins = 0 

toReturn = tolssue = 0 


Jnse.rtCoin. 


Press Ppd 


A{coins) 


A{coins, toReturn) 


coins' = coins + 1 


coins' = coins — 1 
toReturn' = toReturn + 1 




Pressdlreen 




A{coins, tolssue, toReturn) 




coins' = coins — 1 

( tolssue' = tolssue -I- 1 A toReturn' = toReturn 
V 

tolssue' = tolssue A toReturn' = toReturn -I- 1 ) 


Tssue.Ticket 


R.eturnCnin 


A(tolssue) 


A(toReturn) 


tolssue' = tolssue — 1 


toReturn' = toReturn — 1 



Applying the methods described in [2] for translating a Z or Object-Z de- 
scription, via an abstract data type to its corresponding process, and invoking 
the theorem presented in [3] that this translation preserves refinement: 



Theorem One abstract data type is refined by another precisely when 
the process corresponding to the first is refined by the process correspon- 
ding to the second. 
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we see that the process corresponding to our Object-Z description is described 
by ClassDescProcess below. 

ClassDescProcess = 

let 

P{c,t,iss,ret) = 

insertCoin P{c + 1, t, iss, ret) 

□ 

c > 0 & red — >■ P{c — 1, t, iss, ret + 1) 

□ 

c > 0 & green — >■ ( if t > 0 then P{c — 1, t, iss + 1, ret) 
else P{c — 1, t, iss, ret + 1) 

□ 

iss > 0 Sz issueTicket P{c,t — l,iss — 1, ret) 

□ 

ret > 0 Sz returnCoin — >■ P{c, t, iss, ret — 1) 

within 

nt:{0..T}./’(0,t,0,0) 

The integer T is the machine’s ticket capacity. On initialisation it may be filled 
with any number of tickets not exceeding that capacity. Initially no coins have 
been inserted, no coins need returning and there are no tickets waiting to be 
issued. 

5.3 Verifying Consistency 

We prove that our final model of a ticket machine is consistent with the activity 
graph constructed in its development process using refinement. 

In attempting to analyse a UML specification, we must take account of the 
context in which each diagram is presented. In general, activity graphs are in- 
tended only to illustrate a particular use case and so it would be inappropriate 
to infer availability information; hence we use the traces model to compare 
GraphProcess with ClassDescProcess . 

ClassDescProcess C 7 - CraphProcess 

This refinement check tells us that every sequence of methods allowed by the 
activity graph is a possible behaviour of the class description. 

For specifications in which the activity graph is intended to convey availa- 
bility information, we would use the stable failures refinement [ 21 ] rather than 
the traces model employed here. 

6 Adequacy and Application 

Whilst the processes corresponding to our activity graphs defined in Section 4 
and illustrated in the ticket machine example in Section 5 are entirely correct 
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they cannot in practise be used we come to analysing the system using a model 
checker. The interleaving of the process corresponding to each state with itself 
causes the system to diverge. This interleaving is, however, necessary if, for 
instance, we wish to allow the user of the ticket machine to be able to insert two 
coins before they press either the red or the green button. 

To eliminate divergence we must, in Petri net terms, put an upper limit on 
the number of tokens allowed in any place; that is, for each action state and 
activity state we must only allow a finite number of events corresponding to an 
incoming line to occur before an event corresponding to an outgoing transition 
occurs. 

We extend the definition of State to incorporate the variables isDynamic and 
dynamicMultiplity as defined in the official documentation [17]. The Boolean 
isDynamic is True for action states and activity states in which the state’s 
actions may be executed concurrently. If this Boolean is True then the integer 
dynamicMultiplicity limits the number of parallel executions of the actions of the 
state. If the Boolean isDynamic is False, then dynamicMultiplicity is ignored. 

PracticalState 

WellFormedState 
isDynamic : Bool 
dynamicMultiplicity : N 

type G {start, finish, merge, decision, fork, join} isDynamic = False 



We define the functions inComing and outGoing which take a Practical- 
State and return respectively the set of events corresponding to the incoming 
non-looped lines and the set of events corresponding to the lines within the 
non- looped outgoing transitions. Given these definitions, we define the function 
constraint which returns the process which limits the number of parallel execu- 
tions of each state. 

inComing : PracticalState -<->■ P Event 
outGoing : PracticalState -i-^ P Event 
constraint : PracticalState -0- Process 

V state : PracticalState • 

inComing state = eune\ state. lines ) \ aioops state 

outGoing state = {tr ■. state. transitions • eune {tr. line)} \ aioops state 

constraint state = 

let 

Con{n) = 

(n < state. dynamicMultiplicity) & 

□ in : inComing state • in ^ Con{n + 1) 

□ 

□ out : outGoing state • out — >■ Con{n — 1) 

within 

Con{Q) 
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Using these definitions, the process that, for practical purposes, we should 
use to model the behaviour of each state is given below. 

Ppractical_state '■ PracticalStatc -p- EuV -!->■ Process 

Ppracticai state ( state . State • (A euv . Ertv • 

if {isDynamic = False) then Pstate state env 
else 

pstate env |[ {inComing state) U {outGoing state) ]| constraint state 
Hence it follows that, for practical purposes, our semantic function should be 

semanticsP : ActivityLabel -P- EnvP Process 

V env : EnvP', actL : ActivityLabel • 
semantics actL env = 

(|| stateP : statesP'^ {env actL) • 

[ttsiaie stateP CnV ] Ppracticai state statcP Cnv) 

\ U ( ■ statesP^ {env actL) • eune{ stp. lines |}) 

where a EnvP maps activity labels onto “practical” graphs and where practical 
graphs are a collection of PracticalStates. 

EnvP == ActivityLabel -P- GraphP 

GraphP ::= statesP {{ ¥ PracticalState)) 

7 Discussion 

The Unified Modeling Language has many strengths. For instance, its graphical 
nature makes it easily readable by domain experts without a formal mathemati- 
cal training; as such it provides a common ground for discussing the behaviour 
of the system to be developed. In addition, the combination of notations allows 
the user to reason at different levels of rigour and abstraction and from both 
behavioural and state-based perspectives. 

However, as [8] observe, before UML can earn its place as a de facto standard 
for modelling object-oriented systems it must have a precisely defined semantics, 
and not just the precisely defined syntax that it has at present. 

In this paper we have presented a formal behavioural semantics for activity 
graphs. We have illustrated, using a simple example, how this semantic model 
may be used to verify that the behaviour of the final class model description of 
a system is consistent with the behaviour of activity graphs constructed during 
its development process. 

In addition, we have considered the practicalities of integrating such a seman- 
tics into a modelling tool; our syntax corresponds closely to the Rose interchange 
format [20], and we have built constraints into our practical model which will 
prevent the system from diverging. 



Activity Graphs and Processes 



95 



A considerable amount of work remains to be done both in this particular 
area and in the wider scope of UML. In the semantics presented in this paper 
we have built guards into our model, but have not gone into detail as to how 
they should be used. At present we have adopted the most simplistic approach 
in which each guard is a constant value: null or True or False. An interesting 
area of research would be to consider how to model guards which are dependent 
on state variables and the effect that this would have on activity graphs with 
loops and multiple threads. 

In addition, using the behavioural semantics presented here to verify consi- 
stency relies on the assumption that we can translate the final class model to an 
abstract data type and hence to its process equivalent. However the example we 
presented was a simple one with a single class. In theory a single class example 
is sufficient; [11] shows that formal descriptions of models with multiple classes 
and associations can be constructed by promoting the data types that model the 
individual classes. The process of reasoning about these descriptions can then be 
simplified: [25] explains in some detail how refinement distributes through pro- 
motion. However, we need to consider larger, more complex examples to check 
that this method is scalable and practicable. 

Finally, it would be interesting to see if we could link the work presented 
here with that of [10]. Such a link would facilitate the automatic verification of 
consistency between activity graphs and the final java code. 

Whilst these issues still need to be addressed, it is our hope that the work 
presented in this paper, combined with the work done by many others in this 
area, will lead to the automatic verification by modelling tools of the preservation 
within the final class description of both the static and behavioural properties 
captured in UML diagrams. 

Acknowledgements. We would like to thank Jim Woodcock, Perdita Stevens 
and Geraint Jones for their helpful and insightful comments. 
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Abstract. This paper presents a means of structuring specifications in 
real-time Object-Z: an integration of Object-Z with the timed refine- 
ment calculus. Incremental modification of classes using inheritance and 
composition of classes to form multi-component systems are examined. 
Two approaches to the latter are considered: using Object-Z’s notion 
of object instantiation and introducing a parallel composition operator 
similar to those found in process algebras. The parallel composition ope- 
rator approach is both more concise and allows more general modelling 
of concurrency. Its incorporation into the existing semantics of real-time 
Object-Z is presented. 



1 Introduction 

Object-Z [12] is an extension of Z [14] to facilitate specification in an object- 
oriented style. The major extension in Object-Z is the class schema which cap- 
tures the object-oriented notion of a class by encapsulating a single state schema, 
and its associated initial state schema, with all the operation schemas which may 
change its variables. Classes may be incrementally specified using Object-Z’s no- 
tion of inheritance which enables definitions from one class (the inherited class) 
to be implicitly included in another class (the inheriting class). The enhanced 
structuring provided by object-oriented constructs, such as classes, and techni- 
ques, such as inheritance, significantly improve the clarity of large specifications. 

In an earlier paper [13], we showed how Object-Z could be extended to model 
systems with continuous variables and real-time constraints. The approach was 
to provide a semantic basis for combining Object-Z and the real-time notation of 
the timed refinement calculus [9,5]. This notation allows a system to be specified 
by constraints over time intervals on which properties hold. However, the inte- 
grated approach, referred to as real-time Object-Z, did not utilise the structuring 
techniques of Object-Z provided by classes and inheritance. Hence, as presented, 
it is not suitable for large-scale specifications, nor for specifications comprising 
several components such as those of concurrent or distributed systems. 

In this paper, we present an overview of real-time Object-Z (Section 2) and 
provide extensions to utilise Object-Z’s structuring techniques. In particular, 
we show how inheritance can be used to incrementally modify existing class 
specifications (Section 3), and how different classes can be composed to form 
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multi-component systems (Section 4). Two approaches to the latter are consi- 
dered: using the object instantiation technique of Object-Z, and introducing a 
parallel composition operator similar to those found in process algebras. The 
parallel composition operator approach is both more concise and allows more 
general modelling of concurrency. It is also easily incorporated into the existing 
semantics of real-time Object-Z (Section 5). 

2 Real-Time Object-Z 

Real-time Object-Z [13] is an integration of the timed refinement calculus [9,5] 
with Object-Z [12]. It differs from other approaches to specifying continuous and 
real-time systems in Object-Z since 

— it uses only standard notation from Object-Z and the timed refinement cal- 
culus (the approaches of Friesen [4] and Mahony and Dong [7] introduce 
additional notation into schemas of Object-Z classes), 

— it maintains Object-Z’s specification style (the approach of Periyasamy and 
Alagar [10] requires each object to be specified by two classes: one for its 
functionality and one for its real-time properties), and 

— it models the passing of time implicitly (the approach of Dong, et al. [1] 
requires an explicit Tick operation in each class). 

2.1 Timed Refinement Calculus 

The timed refinement calculus is a Z-based notation for the specification and 
refinement of real-time systems. It has been extended with a simple set-theoretic 
notation for concisely expressing time intervals [6] and operators for accessing 
interval endpoints. We adopt a simplified subset of the notation based on that 
of Fidge, et al. [3] which provides a minimal set of operators outside those of 
standard set theory. 

Absolute time, T, is modelled by real numbers and, in this paper, we will 
assume has the units seconds. Observable variables of a system are modelled 
as total functions from the time domain to a type representing the set of all 
values the variable may assume. A system is specified by constraints on the time 
intervals over which properties hold. For example, the following expresses that 
an observable variable w : T — ?► R becomes equal to a differentiable (denoted by 
the function symbol [2]) observable variable w : T R within 0.1 seconds 
whenever w > 10. 

{u > 10) C (,5 = 0.1) ;{v = u) 

The brackets () are used to specify a set of time intervals^. The left-hand side 
of the above predicate denotes the set of all time intervals where, for all times t 
in the intervals, u{t) is greater than 10. 

^ We adopt here a simpler notation than the brackets | ■)] used by Fidge et al. [3] and 
our previous paper [13]. 
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In general, the property in the brackets is any first-order predicate in which 
total functions from the time domain to some type X may be treated as values 
of type X. The elision of explicit references to the time domain of these functions 
results in specifications which are more concise and readable. 

The right-hand side of the above expression comprises two sets of intervals. 
The first uses the reserved symbol S which denotes the duration of an inter- 
val. Hence, this set contains all those intervals with duration 0.1 seconds. Other 
reserved symbols are a and uj denoting an interval’s start and end times respec- 
tively. 

The second set denotes all intervals in which (for all times in the intervals) 
V equals u. It is combined with the first set of intervals using the concatenation 
operator This operator forms a set of intervals by joining intervals from one 
set to those of another whenever their end points meet. (One endpoint must 
be closed and the other open [3]). Hence, the right-hand side of the predicate 
specifies all those intervals where after 0.1 seconds, v equals u. 

The entire predicate, therefore, states (using C) that all intervals where u is 
greater than 10, are also intervals where, after 0.1 seconds, v equals u. 



2.2 Integration with Object-Z 

The semantic integration of the timed refinement calculus with Object-Z was 
presented in our previous paper [13]. In this section, we provide an overview of 
the approach including two new extensions to the syntax. 

Classes in the integrated notation comprise two parts separated by a hori- 
zontal line. The part above the line is essentially the standard Object-Z local 
definitions and schemas. The part below the line is further constraints on the 
class specified in the timed refinement calculus notation. The latter is divided 
into an assumption and effect part as in the timed refinement calculus [5]. All 
state variables x \ X in the Object-Z part above the line are interpreted as timed 
trace variables a; : T — >■ A in the timed trace part below the line. 

Although all real-time properties could be specified in the timed trace part of 
the class, we also allow local constants and state variables of type T and include, 
in every class, an implicit state variable r : T denoting the current time. This is 
captured by an implicit constraint Vf:T*r(f) = fin the timed traced part of 
the class. 

As an example, consider specifying a speedometer which calculates the speed 
of a vehicle by detecting the rotation of one of its wheels: the speed is calculated 
by dividing the wheel circumference by the time taken for a single rotation. 

We assume a maximum speed of 60 metres per second (216 km/hr). 

MaxSpeed == 60 —metres per second 

The speed output by the speedometer is a natural number between 0 and 
MaxSpeed . 



Speed == 0 . . MaxSpeed 



metres per second 
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A system specified by a class in the integrated approach is a digital system 
and, therefore, changes to state variables only occur at discrete points in time. 
However, it may interact with continuously changing variables in its environ- 
ment. These variables are specified as (possibly differentiable) functions of time. 
For example, the speedometer’s environment includes a continuous variable re- 
presenting the angle of the wheel in radians from some fixed position. This can 
be specified as follows. 

I wheel^anglel : T R —radians 

Since this definition gives the values of the wheel’s angle over all time, it 
need not be treated as a modifiable state component and can appear as a local 
constant in the class. The “?” decoration on the name indicates that it is an 
environmental variable that acts as an input to the specified system. Similarly, 
environmental variables decorated with “!” act as “outputs” from the system. 

Our first extension to the syntax allows such outputs to be declared as state 
variables (rather than constants) to indicate that they only change value when 
an operation, whose Z\-list they appear in, occurs. Our second extension to the 
syntax allows operation names to appear as Boolean variables in the timed trace 
part of the class. The variable representing an operation is true in all intervals 
during which the operation is occurring. Examples of these features and the other 
features of a real-time Object-Z class are provided by the following specification 
of the speedometer. 

Speedometer^ 

wheel^cireum == 1.5 —metres 

I wheel-angle? : T R 



last-caleulation : T 
speedl : Speed 

In IT 

last-caleulation < t — 2 * wheel-eireum 
speedl = 0 

CalculateSpeed 

A{last -Calculation, speedl) 

wheel -angle? {t) mod 27t = 0 
V f : (t . . . t' ^ • wheel -angle? {t) mod 27 t yf 0 

last -Calculation' = r 

speedl' = wheel -circum / {t — last -calculation) ± 0.5 

{\ s_ wheel -angle? 2 tt * MaxSpeed / wheel-circum) = (true) 

{wheel-angle? mod 27 t = 0) ; {wheel-angle? mod 27 t yf 0) C 
(true) ; {CalculateSpeed) ; (true) 
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The speedometer calculates the speed (speedl) from the wheel circumference 
{wheel^circum = 1.5 metres) and the wheel angle {wheel ^anglel) which implicitly 
records the number of whole revolutions of the wheel. To do this it keeps track 
of the time of the last speed calculation in a state variable last_calculation. 
Initially, this variable is set to a time more than 2 * wheel-circum seconds before 
the current time r. This ensures that the first speed calculation, when the wheel 
starts rotating, will be zero (since the calculated speed is a natural number with 
units metres per second and a wheel rotation time of more than 2* wheel^circum 
corresponds to a speed of less than 0.5 metres per second). Ensuring the first 
speed calculation is zero is necessary because the wheel may not undergo a full 
rotation before it occurs. 

The operation CalculateSpeed calculates the speed to the nearest natural 
number based on the wheel circumference and the time since the last calculation. 
It is enabled each time the wheel passes the point corresponding to a multiple of 
27 t radians. The first two predicates of the operation ensure that the wheel angle 
mod 27 t is 0 only for the first time instant of the operation. This prevents the 
wheel completing an entire rotation before CalculateSpeed has finished executing. 
(Note that intervals of real numbers can be specified using combinations of the 
brackets ^ ^ for closed intervals and for open intervals.) 

This latter constraint is feasible since the class has an assumption predicate 
which limits the rate of change of wheeCanglel {sv denotes the derivative of a 
differentiable variable v [2]). This assumption also ensures that the speed calcu- 
lated by the final predicate of CalculateSpeed is less than or equal to MaxSpeed. 
(Note that (true) denotes the set of all possible intervals.) 

To ensure that CalculateSpeed occurs every time the wheel passes the point 
corresponding to 0 radians, the class also has an effect predicate which states 
that CalculateSpeed is a sub-interval of any interval where the wheel angle mod 
27t is 0, and then becomes non-zero. 

Note that operations in real-time Object-Z do not have input and output pa- 
rameters: all communication is performed through environmental variables such 
as wheel-angle! and speedl. This restriction enables a straightforward definition 
of refinement as shown in Section 5. 

3 Inheritance 

The speedometer specification of Section 2 works as we would expect when the 
wheel of the vehicle is rotating. If it stops rotating, however, the CalculateSpeed 
operation does not occur and so the speed output by the class is that which was 
last calculated. 

To overcome this problems we could add an operation which detects that the 
wheel is no longer rotating and sets the output speed to 0. Adding an operation 
can be done in standard Object-Z using inheritance [12]. When an Object-Z 
class inherits another it implicitly includes its constants, state schema, initial 
state schema and operations (and may extend these definitions or add to them). 
We extend the notion of inheritance to also implicitly include assumption and 
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effect predicates in the timed trace part of the inherited class. Hence, the desired 
modification to the speedometer can be specified as follows. 

Speedometer 

Speedometer^ 

TimeOut 

A{last ^calculation, speedl) 

T — last_calculation > 2 * wheel-circum 
speedl = 0 

true 

(5^3 + wheel -cir cum) C (true) ; {TimeOut V GalculateSpeed) ; (true) 



The operation TimeOut is enabled when the time since the last calculation 
is greater than 2 * wheeGcircum. This corresponds to a speed of less than half 
a metre per second (1.8 km/hr). The additional effect predicate ensures that 
TimeOut does occur before the time since the last calculation is greater than 

3 * wheel-circum. 

Semantically, inheritance in real-time Object-Z is the same as inheritance 
in standard Object-Z with the addition of conjoining of assumption predicates 
and conjoining of effect predicates from the inherited and inheriting classes. The 
variables and operations in the inherited assumption and effect predicates will 
be renamed to reflect any renaming in the inherited class [12]. 

4 Composition 

To specify systems of concurrent, interacting objects, we need to be able to com- 
pose different classes. For example, consider specifying a cruise control system 
which is required to keep a car travelling at a desired speed set by the driver [8] . 
At any time, the driver can resume control of the car by applying the brake. 

The system comprises three main components: a speedometer, a controller 
which accepts input from the driver, and a throttle which controls the car’s 
speed. It is illustrated in Figure 1. (Arrows indicate the direction of information 
flow.) 

In Section 4.1, we specify the classes for the controller and throttle in such 
a way that they can interact with each other and the speedometer of Section 3 
as shown in Figure 1. In Section 4.2, we look at composing the components 
using standard Object-Z composition and by introducing a parallel composition 
operator. The semantics of this operator is provided in Section 5. 

A fundamental difference between our specification and that of Mahony and 
Dong using TCOZ [8] is our use of continuous variables for modelling the wheel 
angle and throttle inputs from the environment. TCOZ, based on timed CSP, can 
only model discrete events corresponding to reading these variables and cannot 
model the variables themselves. 
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set brake 



accelerator 



wheel_angle 




- throttle 



Fig. 1. Cruise Control System. 



4.1 Component Classes 

The classes for the controller and throttle components are specified using real- 
time Object-Z as described in Section 2. 

Controller. The controller operates in two modes: rest when the speed of the 
car is being controlled by the driver, and set-point when a desired speed has 
been set by the driver and this speed is being maintained by the cruise control 
system. 

Mode ::= rest \ set-point 

Initially, the controller is in rest mode and is changed to set-point when the 
driver presses a button indicating that he or she wants the car to maintain its 
current speed. The controller reverts to rest mode when the brake is applied. 
While in set^point mode, the controller provides the throttle component with a 
desired value of the throttle setting. This is initially the current throttle setting 
and is updated periodically. The updated values of this setting are calculated 
from four parameters 

— the current speed of the car, 

— the desired speed (set by the driver), 

— the speed of the car at the last calculation, and 

— the current value of the throttle. 

We abstractly specify this calculation by the function desired ^throttle. 

I desired _throttle : Speed x Speed x Speed x K — >■ R 
The controller class is specified as follows. 
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Controller 

speed! : T — >■ Speed 
throttle! : T — >■ R 





model : Mode 
controU : R 
desired^speed : Speed 
previous speed : Speed 


Tnit 

model = rest 


Set 

A(model, desired speed , previous speed , controll) 


model' = set-point 
desiredspeed' = speed! (t) 
previous speed' = speed! (t) 
controll = throttle! (t) 


Control 

A(eontroll, previous speed) 


model = set-point 
t' — T < 0.1 

controll = desired-throttle(speed! (t) , desiredspeed , 

previous speed, throttle! (t)) 

previous speed' = speed! (t) 


Ernkp 

A(model) 


model' = rest 




true 



(mode = set-point A S = 0.2) C (true) ; (Control) ; (true) 



The timed refinement calculus predicate states that, when in set-point mode, 
the Control operation occurs in every 0.2 second interval. Since the duration of 
this operation is less than 0.1 seconds (as specified by its second predicate), 
this ensures that the operation occurs repeatedly with a period of less than 0.3 
seconds (see Figure 2). 
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< 0.3 s 



Control 



Control 



<0.1s < 0.2s 





Time 



Fig. 2. Occurrence of Control. 



Throttle. The throttle incrementally adjusts its output to reach a desired target 
output. This target depends on the mode of the controller. If its mode is rest the 
target output is equal to the input from the accelerator, otherwise it is equal to 
the control input from the controller. The throttle class is specified as follows. 

Throttle 

throttle -adjust : R 
mode? : T — ?► Mode 
accelerator? : T R 
control? : T — R 



throttlel : T — >■ R 



Init 

throttlel = 0 



UpdateThrottle 

A{throttle\) 

t' — T < 0.1 
3 t : R • 

{mode?{T) = rest => t C accelerator? (\ D) A 

{mode?{T) = set-point => f = control?{T)) A 
{throttlel < t — 0.5 * throttle-adjust 

throttlel' = throttlel + throttle -adjust) A 
{throttlel > t + 0.5 * throttle-adjust 

throttlel' = throttlel — throttle -adjust) A 
{throttlel € f ± 0.5 * throttle -adjust => throttlel' = throttlel) 

true 

{6 = 0.1) C (true) ; {UpdateThrottle) ; (true) 



The timed refinement calculus predicate states that the UpdateThrottle ope- 
ration occurs repeatedly with a period of less than 0.2 seconds. 
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4.2 Composing the Components 

When composing the components of the cruise control system we need to ensure 

— that the corresponding inputs and outputs (e.g., speed! of Speedometer and 
speed! of Controller) are identified and equated, and 

— that operations which use inputs, do not do so at a time when another 
component is updating the corresponding output. 

The second condition is necessary since the value of a variable updated by an 
operation is undefined for the duration of the operation. This may be, for ex- 
ample, because in an implementation the value is stored as a sequence of bytes 
which are updated one at a time. At any time during the operation, some of the 
bytes may be updated and others not. 

In this section we consider two approaches to composing real-time Object-Z 
classes: object instantiation and parallel composition. 

Object instantiation. In standard Object-Z, systems are composed from in- 
stances of classes called objects [12]. Given an object a, we can refer to a variable 
or constant x of the object’s class by the notation a.x. Similarly, we can refer 
to the initial condition or an operation Op of the object’s class by u.Init and 
a. Op respectively. Adopting this approach, we might specify the cruise control 
system as follows. 

CruiseControl 



s : Speedometer 
c : Controller 
t : Throttle 

s. speedl = c. speed! 
c.mode! = t.mode! 
c.controll = t.eontrol! 

t. throttlel = c. throttle! 



Init 

s.Init a c.Init a Unit 

Calculate Speed = s.CalculateSpeed 

TimeOut = s.TimeOut 

Set = c.Set 

Control = c. Control 

Brake = c. Brake 

UpdateThrottle = t.UpdateThrottle 



CruiseControl comprises an object of each component class and explicitly 
equates their corresponding inputs and outputs. The initial condition and ope- 
rations of CruiseControl are constructed explicitly from those of the component 
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classes. We assume that the real-time predicates of the component classes are im- 
plicitly maintained for each of the objects. We also assume a common r variable 
for each object and CruiseControl. 

The condition that inputs are not used when they are being updated holds 
automatically in this case since the semantics of real-time Object-Z does not 
allow operations within a single class to overlap in time [13] (see Appendix A). 
This means, however, that our system as specified exhibits no concurrency. Con- 
currency can be specified explicitly. For example, the concurrent occurrence of 
operations CalculateSpeed and Brake could be specified by adding an additional 
operation to CruiseControl of the form 

CalculateSpeedSz Brake = CalculateSpeed A Brake 

However, this is an undesirable approach for two reasons. 

1. Explicitly stating all combinations of operations which can occur concur- 
rently may become unwieldy for large systems comprising many components. 
Indeed, even the explicit identification of corresponding inputs and outputs 
and construction of individual operations can be verbose when using object 
instantiation. 

2. The conjoined operations must have the same start and finish times. While 
this allows us to specify synchronising events, it does not allow us to specify 
events which partially overlap. 



Parallel composition. To overcome the problems with specifying concurrency, 
we introduce a parallel composition operator “||” for classes. The idea of this ope- 
rator is that it allows each component to satisfy its specified behaviour over time 
synchronising with other components on environmental variables with common 
basenames (i.e., apart from the “?” and “!”) and on common-named operations. 
Since operations may in general overlap, if we require that two (or more) opera- 
tions should be mutually exclusive in time, this needs to be explicitly specified. 

One way to do this is to specify monitor classes which are composed with the 
components. A monitor class has a set of “dummy” operations (i.e., operations 
which perform no function). These operations comprise a subset of the total 
operations of the specified system which are not allowed to overlap in time. 
Due to the semantics of real-time Object-Z classes, these operations do not 
overlap within the monitor class. Due to synchronisation with the common- 
named operations of the component classes, these operations also cannot overlap 
in time. 

For example, since the Controller operations Set and Control utilise the out- 
put speedl of Speedometer, they should not occur at times when the Speedometer 
operation CalculateSpeed, which changes speedl, occurs. The required monitor 
class is as follows. 



108 G. Smith and I. Hayes 



Monitor sc 

Calculate Speed = [true] 
Set = [ true ] 

Control = [true] 



Similarly, since the Set and Control operations of Controller utilise the out- 
put throttlel of Throttle, we need a monitor class with the operations Set, Control 
and UpdateThrottle . This class also ensures that the mode! and control! outputs 
of Controller are not updated when used by Throttle. 

MonitorcT 

UpdateThrottle = [true] 

Set = [ true ] 

Control = [true] 



By having two separate monitor classes we do not preclude the possibility 
of CalculateSpeed and UpdateThrottle occurring concurrently. The cruise control 
system is specified as follows. 

CruiseControl = Speedometer || Monitorsc II Controller 
II MonitorcT II Throttle 

The definition is both concise (due to implicit modelling of concurrency) and 
allows more general modelling of concurrency (by allowing partially overlapping, 
as well as synchronising, operations). The semantics of the parallel operator is 
discussed in Section 5. 

5 Semantics of Parallel Composition 

Appendix A gives the semantics of a real-time Object-Z class as developed in 
our previous work [13]. A class C is represented by a set of real-time histories. 
These consist of the signature of the class, i.e., its sets of input, output and 
local variables and set of operations, together with traces of the variables and 
the occurrences of operations. A trace is the value of a variable over time. It is 
represented by a total function from time to value. 

Trace == T — >• Value 

An operation is represented by an identifier corresponding to its name. 
Operation == Ident 

From this semantics, we extract a model of a class which we use to define refine- 
ment and parallel composition. This model separates the class’s signature from 
its set of traces and operation occurrences. A signature of a class is specified as: 



Structuring Real-Time Object-Z Specifications 109 



Signature 

inputs^ outputs, locals : F Ident 
opids : F Operation 



and a history as: 

RTHistory 

trace : Ident Trace 
occurs : Operation PI 



where I is the set of all time intervals. 

A class is then modelled as follows. 

RTClass 

sig : Signature 
histories : P RTHistory 

V h : histories • 

dom h .trace = sig. inputs U sig. outputs U sig. locals A 
dom/i. occurs = sig. opids 



Since the only communication mechanism between classes is environmental 
variables, and environmental inputs cannot be constrained by a class [13], all 
information about when operations can be refused by a particular class are 
captured by its histories. Hence, a class, C, is refined by a class, D, if C and D 
have the same signatures and the histories of C contain the histories of D. 

_ C _ : RTClass -fA RTClass 

C C D C .sig = D.sig A D .histories C C .histories 

When two classes are composed, the signature of the resulting composite 
class has those inputs of either class which are not also an output of the other 
class. That is, inputs which have the same name as an output in the other class 
are semantically identified with this output and no longer appear as an input to 
the composite class. This models the output’s value being communicated to the 
input. 

The outputs, local variables and operations of a composite class are those 
from either class. The outputs and operations which are common to the com- 
ponent classes must satisfy the constraints of both classes within the composite 
class. (We assume that the local variables of the component classes are distinct. 
Our semantics could be made more general by adding some form of renaming to 
ensure this, thus removing the need for this assumption.) 

The binary operator comp composes the signatures S and T of two classes. 
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_ comp _ : Signature x Signature -!->■ Signature 

{S, T) £ dom(_comp_) S.loeals fl T.loeals = 0 A 

{S comp T).inputs = {S. inputs \ T. outputs) U {T .inputs \ S. outputs) A 

{S comp T). outputs = S. outputs U T .outputs A 

{S comp T).loeals = S.loeals U T.loeals A 

(S comp T).opids = S.opids U T.opids 

The comp operator is commutative and associative. 

The history of a component class can be derived from a history of a composite 
class by restricting the history of the composite class to the component class’s 
signature. 

The binary operator restrict extracts, from a real-time history h, a history 
corresponding to the signature b” of a component class. 

_ restrict _ : RTHistory x Signature RTHistory 

{h restrict S).trace = {S. inputs U S. outputs U S.loeals) <1 h. trace A 
(h restrict S). occurs = S.opids <1 h. occurs 

The parallel combination of two classes, C \\ D, has a signature which is the 
composition of the signatures of C and D. Each of the histories of the parallel 
combination, if restricted to the signature of C (respectively D), is a trace of C 
{D). 

_ II _ : RT Class x RT Class -O- RT Class 

(C,D) G dom(_ II _) {C.sig, D.sig) G _ comp _ A 
(C II D).sig = C.sig comp D.sig A 
(G II D).histories = {h : RTHistory \ 

h restrict C.sig G C .histories A 
h restrict D.sig G D .histories} 

Parallel composition of classes is commutative and associative. Furthermore, it 
is monotonic with respect to refinement in both its arguments. 

6 Conclusion 

In this paper, we have shown how Object-Z’s class and inheritance constructs 
can be used to structure specifications in real-time Object-Z: an integration 
of Object-Z with the timed refinement calculus. In particular, for composing 
Object-Z classes to form multi-component systems, we have introduced a paral- 
lel composition operator similar to those found in process algebras. This operator 
provides a means of composition which is both concise (due to implicit modelling 
of concurrency) and allows more general modelling of concurrency (by allowing 
partially overlapping, as well as synchronising, operations) . The existing seman- 
tics of real-time Object-Z was extended to accommodate the parallel composi- 
tion operator in such a way that the operator is commutative, associative and 
monotonic with respect to refinement. 
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A Semantics of Real-Time Classes 

To provide a semantics for our integrated notation, we show how to map the 
standard Object-Z semantics to timed traces. Smith [11, §2.3] gives a history 
model for an Object-Z class in terms of sequences of states and operations. We 
introduce that semantics and then show how to relate it to timed traces. 

A.l Histories 

Let I dent denote the set of all identifiers, and Value the set of all values of any 
type. A state is an assignment of values to a set of identifiers representing its 
attributes. It can be defined by a finite partial function from identifiers to values: 

State == Ident Value. 

An operation can be defined as an identifier corresponding to the operation’s 
name (since operations do not have input and output parameters in real-time 
Object-Z): 

Operation == Ident 

The history of an object consists of (possibly infinite) sequences of states 
and operations. The sequence of states is non-empty as there must be at least 
an initial state. The set of attributes of every state in the sequence comprises 
the state variables of the object’s class^ and hence must be the same. If the 
sequence of operations is finite, then the sequence of states has the initial state 
plus an element corresponding to the final state of every operation. Hence the 
sequence of states is one longer than the sequence of operations. If the sequence 
of operations is infinite, then so is the sequence of states. 

These conditions are captured by the following schema where seq^ X == 
seqA U (Ni — ?► X). For state variables corresponding to environmental outputs, 
attributes contains their names without the “!” decoration. The fact that they 
are environmental outputs is captured in TraceHistory (Section A. 3). 

History 

states : seq^^ State 
ops : seq^ Operation 
attributes : F Ident 
opids : F Operation 

states yf () 

V i : dom states • dom( states i) = attributes 
ran( ops) C opids 

V t : Ni • t € dom ops <G> t -I- I € dom states 



^ In Smith’s model [11] the attributes of states include, as well as state variables, all 
constants the object’s class can refer to. Here we take an alternative view that the 
values of such constants are parameters to the semantics. 
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A. 2 Start and Finish Times 

To map histories to timed traces, we extend the standard definition of an Object- 
Z history given above. The first extension is to allow for the start and finish 
times of each operation. The variable start denotes the sequence of start times 
of operations, and the variable finish denotes a sequence, with indices starting 
from 0, of finish times. We use finishifS) to represent the time at which the 
initialisation completed, and if the sequence of operations is finite we add an 
extra start time, with value oo, representing that after the last operation, the 
state is stable forever. 

TimedHistory 

History 
start : seq^ T 
finish : N T 

\f i :N • i € dom ops f + 1} C dom start 

dom start yf Ni => last(start) = oo 
dom finish = {0} U dom ops 

V i : dom ops • start(i) < finish{i) 

V i : dom finish] j : dom start • i < j ^ finish(i) < start{j) 



A. 3 Timed Traces 

The next extension is to add timed traces of variables. The timed trace of a 
variable is a mapping from time to the value of the variable at that time. 

Trace == T — >• Value 

We add a timed trace for every environmental variable and each state variable 
of the class. The names of environmental variables appear in the semantics with- 
out their “?” or “!” decorations. This information is captured instead by three 
sets of identifiers: inputs for environmental inputs, output for environmental ou- 
tputs, and locals for local state variables. The local state variables are a subset 
of the attributes, the remainder of the attributes being environmental outputs. 

The conditions under which a timed trace corresponds to an Object-Z history 
is defined below. 

TraceHistory 

TimedHistory 

inputs^ outputs, locals : F I dent 
trace : Ident -«> Trace 

{inputs, outputs, locals) partitions(dom trace) 
locals C attributes 
attributes C locals U outputs 
Vi : dom states; id : attributes • 

{trace id)(\ ^finish{i — 1) . . . start{i)^ [) = {{states i){id)} 
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A trace of a state attribute is stable with value states {i) from the finish time 
of an operation, finish(i — 1), until the start time of the next operation, start(i). 
The initial state, states (1), is stable from the finish time of the initialisation, 
finish{0), and, if the sequence of states is finite, the final state after the last 
operation is stable until the start time of the end-of-time event, i.e., infinity. Note 
that the value of the state trace is only determined for the stable periods between 
operations; it may be any value during the execution time of an operation. 

A. 4 Operation Intervals 

We extend the definition further to include the intervals in which particular 
operations occur. This allows the timed trace part of a class to refer to times 
when a particular operation is occurring. 

Intervals are contiguous sets of times: 

I : P(PT) 

I = {/ : T I {inf {I) . . . sup{I)) C /} 

where inf (I) and sup{I) stand for the infimum (greatest lower bound) and su- 
premum (lowest upper bound), respectively, of the set / [2]. 

For each operation in the Object-Z history, the set of time intervals over 
which it occurs is just the set of intervals between its start and finish times. 
From the constraints on start and finish times, no two of these intervals can 
overlap by more than just a single point of time. 

RealTimeHistory 

TraceHistory 

occurs : Operation PI 

occurs = {X op : opids • 

{i : dom ops \ ops{i) = op • ^start{i) . . . finish (i)^}) 



The function occurs is derived from the ops sequence. 

A. 5 Class Histories 

An Object-Z class defines a possible set of histories for objects of that class. Smith 
[11] gives a function 'H which given a class returns a set of possible histories of 
that class. We extend this function to map the Object-Z part of a class in our 
notation to a set of real-time histories, i.e., histories extended as in the previous 
sections. 

I T-L : Class — >■ V RealTimeHistory 

The details of Class and the mapping from a class to a set of real-time histories 
are the same as those given by Smith [11]^, except that in operation specifications 

The type we refer to as Class is called ClassStruct in Smith. 



3 
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references to r and r' correspond to the start and finish times, respectively, 
of the operation. In addition, the semantics need to allow direct references to 
the environmental variables; such references treat an environmental variable as 
an explicit trace. The formalisation of these additional relationships within the 
framework used by Smith [11] is straightforward and we do not give the details 
here. 

A. 6 Timed Trace Predicates 

To give the semantics of a class in our notation, we also need to consider the 
timed trace part of the class. A timed trace predicate defines a set of real-time 
histories that satisfy the predicate. Let TimedTracePred denote the set of all 
timed trace predicates. 

I traces : TimedTracePred — ^ ¥ RealTimeHistory 

A real-time history, h, satisfies a timed trace predicate if the predicate is true 
when we replace any reference to a trace variable, v, by the corresponding value, 
h.trace(v). To allow operations in such predicates to represent Boolean values 
which are true in the sets of intervals in which they occur, we also need to replace 
any reference to an operation, op, by true in intervals in the set, h.occurs(op), 
and false elsewhere. 

An interval expression, such as (P), where P is a predicate, is interpreted as 
the set of intervals such that P holds at all points in the interval: 

{(/) : I I 3 a, w, (5 : T • a = inf{4>) /\ uj = sup{4>) A <5 = w — a A 
y T \ 4> * P[v(t) j 'll]} 

where v stands for the vector of all timed trace variables, i.e., dom trace. 

A class in our notation consists of the standard class components (augmen- 
ted with environmental variables) and two real-time predicates specifying res- 
pectively the assumptions the class makes about environmental variables and 
the effect the class is to achieve on environmental variables. 

RealTimeClass 

class : Class 

assumption, effect : TimedTracePred 



The possible real-time histories of such a class C consist of those histories 
that, if the assumption holds, also satisfy the effect and are real-time histories 
of the corresponding Object-Z part of the class. 

TZ : RealTimeClass — >■ ¥ RealTimeHistory 

TZ{C) = {h : RealTime History \ h € traces {C .assumption) 

h € traces{C .effect) (^^-[{C. class)} 
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Abstract. This paper introduces the ISpec approach to interface spe- 
cihcation. ISpec supports the development of interface specifications at 
various levels of formality and detail in a way compatible with object- 
oriented modelling techniques (UML). The incremental nature of the 
levels and the underlying formal framework of ISpec allow informal in- 
terface specifications to be made formal in steps. The body of the paper 
consists of a discussion of the main characteristics of ISpec, which re- 
flect the important decisions taken in the design of ISpec. The idea of 
component-based specifications and specification plug-ins for construc- 
ting heterogeneous specifications is discussed and a small example sho- 
wing the various levels of specification supported by ISpec is presented. 



1 Introduction 

1.1 The Role of Interfaces 

Interfaces play a role of increasing importance in modern software development. 
One reason for this is the current trend towards the use of open systems. The SEI 
definition of open system [15] clearly indicates why interfaces, and in particular 
interface specifieations, are essential in open systems: 

“An open system is a collection of interacting software, hardware, and 
human components 

— designed to satisfy stated needs 

— with interface specifications of its components that are 

• fully defined 

• available to the public 

• maintained according to group consensus 

~ in which the implementations of the components conform to the 
interface specifications” 

Another reason for the increasing importance of interfaces is the growing use of 
component-based software development techniques [19]. This trend is supported 
by the availability of standard component models such as COM, CORBA and 
Java Beans. Components use interfaces to make their context-dependencies ex- 
plicit. This use of interfaces as a decoupling mechanism can be seen as the crux 
of component-based software development. 



W. Grieskamp, T. Santen, and B. Stoddart (Eds.): IFM 2000, LNCS 1945, pp. 116—135, 2000. 
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1.2 Objectives of ISpec 

ISpec is an interface specification approach developed by Philips Research with 
the aim of providing a systematic approach to interface specification that 

1. supports multiple levels of formality and detail] 

2. fits in with main-stream object-oriented modelling techniques (UML); 

3. has a solid footing in formal techniques] 

4. provides a basis for systematic testing. 

These objectives are based on our past and recent experience with the use of for- 
mal and informal specification techniques in several product divisions of Philips; 
see e.g. [5,13]. As many formal methodists have learned the hard way, formal 
techniques are considered a problem rather than a solution by the average soft- 
ware developer in industry. We therefore aim at an approach that can also be 
used informally and with varying degrees of detail, rather than an all-or-nothing 
formal approach (objective 1). 

Despite the aversion to formal techniques displayed by many industrial soft- 
ware developers, there is a general feeling that better techniques for control- 
ling the complexity of software are required. The growing popularity of object- 
oriented modelling techniques, and in particular UML, can be seen as a sign of 
this. We consider it important to fit in with this trend (objective 2), not just 
because it is opportune to do so but above all because the idea of object-oriented 
modelling and the formal-methods idea of ‘abstract modelling’ are closely related 
(see Section 2.4). 

The unbridled use of informal techniques can easily lead to unstructured 
and inconsistent specifications. This can be avoided by choosing an appropriate 
formal framework as the basis of the approach and structuring specifications in 
such a way that the various parts of a specification, whether informal or formal, 
can be related unambiguously to parts of that framework (objective 3). Hence, if 
necessary, an ISpec interface specification can be made ‘completely’ formal. We 
put ‘completely’ between quotes because there are always aspects of interfaces 
that can only be expressed informally. 

Another reason why it is important to have a formal basis is to be able 
to provide semantic tool support. The intention is to support the automatic 
generation of black-box tests from an ISpec specification (objective 4). The price 
to be paid for this is that the specification, or at least part of it, has to be made 
formal. Though this price may be high, there are potentially large benefits to be 
gained in the testing phase. We do not consider the practical use of proof tools 
a viable option yet, though there could be special situations in which it is. 

ISpec focusses on the specification of interfaces as encountered in component 
technologies such as COM and CORBA. Compared with classical APIs, such 
as Win32, OpenCL, etc. which are monolithic and static, these interfaces are 
typically small and dynamic. Furthermore, we generally have to deal with a 
group of mutually related interfaces, a so-called interface suite, rather than a 
single interface. This focus on component interfaces is not really a restriction 
since a classical API can be seen as a special case of an interface suite (with one 
element). 
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2 Main Features of ISpec 

2.1 Contractual View of Interface Specifications 

The idea of using a contractual paradigm in software development has been 
advocated by many researchers, in particular by Meyer [12]. The contractual 
paradigm is fundamental to the ISpec approach. An interface specification in 
ISpec is viewed as an unsigned multi-party contract between providers of services 
and users of services, as will be further explained below. It contains, among other 
things: 

— An identification of the services, interfaces and parties involved in the con- 
tract. This serves primarily to introduce names and types for the services, 
interfaces and parties, leaving the entities themselves as yet undefined. 

— A definition of the relevant terms and concepts. This can be seen as an 
information model defining the necessary vocabulary for the contract. In 
practice, the definitions may be drawn from a more comprehensive domain 
model. 

— A definition of the rights and duties of each party. In specifications these 
rights and duties are formulated using terms such as: requires and provides, 
relies and guarantees, assumes and ensures, precondition and postcondition, 
etc. 

The contract is multi-party because several parties may be involved in the con- 
tract, and not just one or two. This is due to the fact that component interfaces, 
unlike monolithic APIs, are generally small and dedicated to a particular aspect 
of a service. The overall service is defined by a collection of interfaces, also cal- 
led an interface suite. Because of mutual dependencies, the interfaces in a suite 
cannot be separately specified. Since each interface has at least a provider and 
a user, this leads to multiple parties in the contract. An example of an interface 
suite is the collection of ‘connection point’ interfaces from Microsoft COM, de- 
fining a generic notification service. The interfaces and parties, and their main 
dependencies, are indicated in the UML class diagram in Figure 1. 

The contract is unsigned in the sense that the parties identified in an inter- 
face specification are abstract, i.e. they are roles and not physical entities. In 
ISpec specifications these parties are represented as abstract object classes. In 
reality, the roles are played by concrete parties that implement (their part of) 
the contract. These concrete parties are usually defined as object classes in pro- 
gramming languages such as Java and C-| — h. In order to determine whether an 
interface specification as a whole has been correctly implemented, we must first 
associate a concrete party with each abstract party identified in the contract. 
That is, the contract must be signed] see Figure 2. 

Note that a concrete party can play several roles, as a provider as well as a 
user of interfaces, and that it can be involved in several contracts. Note also that 
the provider and the user of an interface are treated in the same way in ISpec 
in the sense that both may be subject to specification constraints, and not just 
the provider of the interface. 
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Fig. 1. Microsoft COM’s Connection Point Interface Suite 




2.2 Incremental Levels of Detail and Formality 

One of the explicit objectives of ISpec is to support interface specifications at 
different levels of detail and formality. In order to enable a smooth transition 
from one level to the next more detailed or formal level, these levels have been 
chosen so that they are incremental. This implies that a level n + 1 specification 
is obtained from a level n specification by adding new sections to the specifica- 
tion. The existing sections retain their function, though their contents may be 
adjusted to the newly added detail. For example, adding a UML class diagram to 
an informal specification can enable an informal requirement to be made more 
precise by phrasing it in terms of the entities and attributes occurring in the 
diagram. 
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In ISpec six specification levels are identified, as characterised below: 

1. IDL level: Defines the signature of the interfaces in terms of some IDL (In- 
terface Definition Language) . Though most IDLs have (very) limited ways of 
expressing semantic attributes of interfaces, they basically define the syntax 
of interfaces only. 

2. Summary level: Adds operation summaries to the interfaces, informally and 
succinctly describing the effect of the operations in the interfaces. This style 
of specification corresponds more or less to the current state of practice. 

3. Model level: Adds an object-oriented model to the specification, typically in 
UML, with abstract object classes representing the parties in the contract. 
The effect of the operations in an interface is described informally in terms 
of the attributes of the abstract class providing the interface. 

4. Action level: Adds action clauses to the operations, defining the effect of the 
operations in a pseudo-algorithmic way. This corresponds to an operational 
style of specification similar to pseudo-code. 

5. Pre & Post level: Adds preconditions and postconditions and other declara- 
tive elements such as invariants to the operation specifications. The action 
clauses are still used at this level, but they are usually more abstract than 
at the action level (see Section 2.5). 

6. Formal level: Adds formal text and turns the interface specification into a 
complete formal specification. This level of formality is not normally used in 
practice, unless formal verification or automatic test generation is required. 

The above gives a rough description of each level only. A simple example de- 
monstrating the above levels will be presented in Section 4. 

2.3 Template-Based Approach 

Rather than providing a concrete syntax for interface specifications, ISpec defi- 
nes a document structure which is essentially a tree structure of templates, such 
as templates for specifying data types, classes, operations, etc. These templates 
are similar to the kinds of templates used in object-oriented methods such as 
Catalysis [17]. The levels of detail discussed in Section 2.2 correspond to incre- 
mental levels in the tree structure. 

The ISpec document structure identifies logical components of specification 
documents. The corresponding physical documents will generally have a project- 
dependent structure and will contain additional components not defined by 
ISpec. These documents may appear in various representations such as MS Word 
or Rational Rose format. A part of the logical document structure is shown in 
Figure 3 using UML class diagrams as a kind of abstract syntax. 

Informal and formal text occurs at the leaves of the document tree structure 
only. This raises the immediate question what language to use for the formal 
text and what the semantics of a specification structured like this is. This issue 
will be discussed in Section 3. 
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Fig. 3. Part of the ISpec Document Structure 

2.4 Abstract Modelling as a Basis 

Specifying a system by means of an abstract model, also called abstract model- 
ling or model- oriented specification, amounts to defining an ‘abstract implemen- 
tation’ of the system. A concrete implementation is said to conform to such a 
specification if its observable behaviour is consistent with that of the abstract 
implementation. 

The abstract model differs from a real implementation in the use of program- 
ming variables with abstract types such as sets, relations, functions, etc., and the 
use of declarative constructs such as pre- and postconditions rather than code to 
specify operations. One of the first formal methods supporting model-oriented 
specification was VDM [10]. 

ISpec uses abstract modelling as the basis of interface specifications. The first 
reason for this choice is that it constitutes a good compromise between providing 
a high level of abstraction and providing a high level of intuition. For software 
developers it is generally easier to think in terms of constructive models than in 
terms of non-constructive properties, even though, or maybe because, the use of 
models may introduce implementation bias in specifications. The second reason 
is that the technique fits in quite well with object-oriented modelling techniques, 
making it easier to bridge the gap between formal techniques and UML. 

An abstract model is defined in an ISpec interface specification by represen- 
ting each party in the contract by an abstract object class and associating each 
interface type with the object class representing the provider of the interface. 
This implies, among other things, that each object class may have zero, one, 
or more interfaces and that in a real implementation two different abstract ob- 



122 



H.B.M. Jonkers 



ject classes may correspond to the same concrete class, playing two roles at the 
same time. For each abstract object class an internal representation is chosen 
in terms of abstract state variables, and the required and provided behaviour of 
the parties is specified in terms of the abstract state variables. 

The approach described above is very similar to the way interface behaviour 
would be modelled in UML, but there are some differences. The first is that the 
current version of ISpec does not use UML’s assertion language OCL, mainly 
because OCL lacks formality and expressivity. Instead, the current version of 
ISpec uses the assertion language and type mechanism of Z [18], in a way similar 
to Object-Z [14]. The intention is to make ISpec independent of the assertion 
language used; see Section 3. 

The second difference has to do with the ‘impressionistic’ way UML is used 
in practice. UML models are typically defined by drawing lots of diagrams high- 
lighting various aspects of the model without making the model itself explicit; see 
Figure 4. ISpec is based on an ‘expressionistic’ way of modelling in the sense that 
the UML diagrams are used as an expression of an explicit model, thus making 
it a lot easier to guarantee consistency. This raises the question exactly what 
that model is, an issue that will be addressed in Section 2.6. The above is not 
to say that the impressionistic approach has no value; both styles of modelling 
are useful but they serve different purposes (see Section 2.7). 





Fig. 4. Impressionistic versus Expressionistic Modelling 



2.5 Mixed Declarative/ Operational Style 

In specifying the effect of operations ISpec uses an extended form of the pre- and 
postcondition technique based on the extensions described in [II]. An operation 
specification is split into effect specifications specifying the effect of the operation 
under different circumstances defined by preconditions. An effect specification 
can be seen as a mini- contract between the caller and the callee of an operation. 
The structure of an effect specification and its interpretation as a mini-contract 
is indicated in Figure 5. 
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Fig. 5. ISpec Effect Specification Template 

The part of the effect specification that is different from a classical pre- and 
postcondition specification is the action clause. The action clause specifies a 
collection of allowed state transitions in an operational way, using abstract and 
often non-deterministic algorithmic constructs. This collection of state transi- 
tions acts as a kind of upper limit for the nondeterministic behaviour of the 
operation. The pre- and postcondition clauses are used to further constrain this 
set of state transitions in a declarative way. 

The combined use of the action clause and the pre- and postcondition clau- 
ses allows an operation to be specified in a mixed declarative/operational style, 
which is important for a number of reasons. First of all, certain aspects of ope- 
rations are inherently operational and very hard to specify declaratively. This 
applies for example to the call-backs performed by an operation. Call-backs are 
a phenomenon frequently encountered in component-based software. Secondly, 
some operations can simply be specified more naturally in an abstract algorith- 
mic way than in a purely declarative way. This applies particularly to control-like 
operations. Finally, the action clause can be generalised in such a way that it 
allows the specification of non-atomic operations, such as blocking operations 
and operations with internal interaction points. 

The ratio between declarative and operational content in an operation spe- 
cification can in principle be chosen arbitrarily. One extreme is that the action 
clause is only used to indicate which variables may be modified by the opera- 
tion, and the precondition and postcondition are used to define the effect of the 
operation. This corresponds to the classical use of pre- and postconditions as in 
VDM-SL [10] or the Larch behavioural interface specification languages [8]. The 
other extreme is that the action clause is a piece of pure program code and that 
the precondition and postcondition are omitted. The example below is some- 
where in the middle of the spectrum, specifying an operation that increments a 
counter and notifies the objects in the set subscribers after every 100 ticks. Since 
in this case the operation specification consists of a single effect specification, 
the effect specification is identified with the operation specification: 

operation tick() 

pre true 

action modify counter 

; if counter = 0 mod 100 then for s : subscribers do s.notify() 

post counter = counter' + 1 
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Here the for-clause iterates over the elements of a set in an unspecified order. 
We note that problems with re-entrancy of call-backs, such as s. notify () modify- 
ing the value of counter ^ can be avoided in ISpec in a simple and natural way. 
ISpec uses the closed world assumption in the sense that (abstract) state varia- 
bles introduced in an interface specification can be modified by means of the 
mechanisms identified in that specification only. Any call-back interfaces used 
by the operations being specified are part of the interface specification and any 
possible effect of their operations on the state variables should be specified as 
part of the interface specification. Clearly we do not want s.notify() to modify 
the state variable counter of the notifying object, which can be specified in the 
specification of the call-back interface containing the notify() operation. 

2.6 Transition Systems as Semantic Model 

One of the main objectives of ISpec is to support interface specifications at dif- 
ferent levels of formality. In order to maintain consistency between the informal 
and semi-formal parts of a specification on the one hand, and the formal parts on 
the other hand, it is essential that both are based on the same semantic model. 
This means that the semantic model must be both intuitive and formal, which 
is not an obvious combination. ISpec uses the transition system model [16] as 
its underlying semantic model, which is believed to satisfy these requirements. 
This will be further explained and motivated below. 

Transition systems have a long-standing reputation as semantic models for 
concurrent systems. In its basic form a transition system consists of a collection of 
states, an initial state, a state transition relation defining which state transitions 
may occur, and a set of progress rules defining when state transitions will occur. 
The progress rules can be formulated in various ways, such as very abstractly, 
based on some notion of fairness, or very concretely, based on some notion of 
real-time triggering. 

The basic transition system model is very simple and easy to explain. Besides 
that, it has other advantages, such as: 

— it fits in with traditional finite state black-box testing techniques [1]; 

— it can be used to unify the concepts of callable operation and autonomous 
transition, leading to a uniform treatment of both; 

— it helps in suppressing ‘control-bias’ in specifications by the absence of ‘loci 
of control’. 

The only problem is that the basic transition system model is too austere and un- 
structured. For specifications of component interfaces we need an object-oriented 
semantic framework. Fortunately, creating such a framework is mainly a matter 
of extending the transition system model without affecting the essentials of the 
model. A short reconstruction of the enhanced transition system model used 
in ISpec is given below. The enhanced model is obtained by taking the basic 
transition system model and successively adding the following concepts: 
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— Classes: introduce collections of objects and provide a natural way of structu- 
ring states, transitions, and progress rules. State is aggregated in the instance 
variables of objects, transitions are aggregated in the operations of objects, 
and progress rules are aggregated in the activities of objects. 

— Interfaces: introduce information hiding by defining the external access me- 
chanisms of objects. ISpec interfaces contain operations only and no instance 
variables, so instance variables are always hidden. 

— Observability: defines which part of the behaviour of the model is externally 
observable. This is required to define conformance. Observable behaviour is 
not the same as behaviour observable at the interfaces, because behaviour 
may also be observable by other means, such as connected hardware repre- 
sented by certain classes in the model. 

— Factories: are special classes providing constructors for objects. ISpec classes, 
like component classes in COM, do not have static methods. Constructors are 
considered normal operations of objects, creating a chicken-and-egg problem 
that is solved by factories. Factories are special in only one sense: they do 
not have explicit constructors. 

The concept of abstract model discussed in Section 2.4 should not be con- 
fused with that of transition system. Abstract models are syntactic entities^ 
like programs, while transition systems are semantic entities. The link between 
the two is that abstract models corresponding to ISpec interface specifications 
describe transition systems. Due to the presence of declarative constructs in ab- 
stract models, the transition system described by an abstract model need not 
be unique. The meaning of an ISpec interface specification, therefore, is defined 
as the collection of all transition systems described by the abstract model. 

Note that the above requires an adjustment of the notion of conformance. 
An implementation conforms to an ISpec interface specification if its observable 
behaviour is consistent with the observable behaviour of at least one transition 
system described by the specification; see Figure 6. 
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Fig. 6. Conformance to an ISpec Specification 
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2.7 Separation of Modelling Concerns 

ISpec is essentially an approach to developing an interface specification docu- 
ment. Such a document is the result of an interface engineering activity and is 
usually released at the time the interfaces are released to customers. Besides a 
contractual function, this document also has an introductory and explanatory 
function. These two functions require different perspectives in the presentation 
of the interfaces and are dealt with in separate sections of the document referred 
to as the contractual model and the conceptual model. 

The purpose of the conceptual model is, among other things, to 

— introduce the important terms and concepts necessary to explain the func- 
tionality associated with the interfaces; 

— explain the purpose and functionality of the interfaces; 

— provide the link with the interface requirements] 

— introduce the outlines of the abstract model. 

In the conceptual model the primary concern is providing the proper intuition, 
rather than accuracy and completeness. The impressionistic style of modelling 
discussed in Section 2.4 is the most appropriate in providing that intuition, 
using UML diagrams showing various aspects of the interface functionality and 
deliberately ‘forgetting’ certain details of the abstract model. 

Besides separating the conceptual aspects of interface specifications from the 
contractual aspects, it also makes sense to separate the technology-independent 
aspects from the technology-dependent aspects. By ‘technology’ we mean the 
programming language and/or component technology in which the interfaces 
are supposed to be used. The contractual model is therefore split into two parts: 

— a technology-independent part referred to as the specification model, specify- 
ing the interfaces in terms of a neutral Java-like class model; 

— a technology-dependent part referred to as the technical model, mapping the 
technology-independent specification to the component technology and/or 
programming language used. It defines the representation of the interfaces 
in terms of the technology used and the relation between the technology- 
independent and the technology-dependent concepts associated with the in- 
terfaces. 

Note that the technical model can be defined by a generic mapping, requiring 
only one definition that can be used for all interfaces defined in a project. This is 
similar to the way some automatic Java to COM interface mappings are defined 
at the programming language level. 

The main advantages of the technology abstraction used in the specification 
model are: 

— Clarity: Specifying interfaces in terms of technology-oriented concepts clut- 
ters up interface specifications, which is now avoided. 

— Reuse: The same technology-independent specification can be used for va- 
rious incarnations of the interfaces in, for example, COM, CORBA, Java or 
C++. 
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The main document structure of an ISpec interface specification is indicated 
in Figure 7, showing the separation into conceptual, specification and technical 
models, as well as other parts of the document structure. 
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Fig. 7. ISpec Main Document Structure 



3 Component-Based Specifications 

ISpec is meant to be an open approach to the development of interface specifica- 
tions. This is reflected by, for example, the absence of bias towards a particular 
component technology or programming language. There is one question, though, 
that seems inevitable: which specification language should be used for the for- 
mal parts of an ISpec interface specification? It is one of the longer term goals 
of ISpec to turn this question into a non-question and provide openness with re- 
spect to the specification language used as well. The key to solving this problem 
lies in the basic idea of component technology and interfaces itself. 

Component technologies with a binary interface standard such as COM are 
open with respect to the programming language used to implement components. 
Components can be implemented in any language and which language is used 
is irrelevant to the users of components. The interfaces shield the details of the 
implementation language from the users of the components. We can use the same 
idea at the specification level, as will be explained below. 

The issue which specification language to use becomes important at the ‘lea- 
ves’ of the ISpec document structure, at those points where an assertion, expres- 
sion, etc. is expected. Examples of such leaves are the precondition, action and 
postcondition clauses discussed in Section 2.5. Ideally we would like to be able to 
‘plug in’ descriptions written in different specification languages at these points; 
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see Figure 8. Viewing the plug-ins as components and using the analogy with 
component technology, it follows that this requires the definition of interfaces 
that shield the details of the specification language used in the plug-ins. 
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Fig. 8. The Idea of Specification Plug-ins 

What should the interfaces of specification plug-ins look like? First of all, 
the interface of a plug-in should be bidirectional since it provides information to 
as well as requires information from the environment into which it is inserted. 
Since plug-ins are essentially language constructs, such bidirectional interfaces 
are most conveniently represented by sets of synthesized and inherited attributes 
as in attribute grammars. 

The attributes in a plug-in interface can be divided into syntactic and se- 
mantic attributes. The values of syntactic attributes are syntactic objects such 
as identifiers, types, etc. The values of semantic attributes are semantic objects 
such as states, valuations (mappings from names to values), etc. 

Each type of plug-in has its own interface specification, defining the names 
and types of the synthesized and inherited attributes occurring in the interface 
as well as possible constraints on the values of the attributes. At a point in the 
document structure at which a plug-in of a particular type is expected, such as 
a ‘precondition’ or an ‘action clause’, any plug-in inserted at that point should 
satisfy the interface specification associated with that type. 

The component-based specification set-up sketched above leads to a fully 
compositional approach to the semantics of a multi-language ISpec interface 
specification. The semantics is defined in terms of the structure of the specifica- 
tion and the semantics of the individual plug-ins occurring in the specification. 
The semantic definition refers to the attributes in the interfaces of plug-ins only 
and is thereby fully independent of the specification languages used in the plug- 
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ins. The semantics of each individual plug-in, on the other hand, is of course 
determined by the language the plug-in is written in. 

The approach described above is still tentative and subject of ongoing rese- 
arch. The current version of ISpec uses a blend of COLD and Z as its formal 
basis. Essential to the overall approach is the use of a uniform semantic model 
in terms of which expressions from different specification languages can be inter- 
preted and in terms of which the attributes of plug-in interfaces can be defined. 
The role of this model can be compared with that of the binary standard in 
COM, although it is of a completely different, semantic, nature. The transition 
system model discussed in Section 2.6 is the obvious candidate for this model. 

4 A Simple Example 

4.1 Iterator Interface 

In this section we will give a simple example of an interface specification, de- 
monstrating the levels of detail and formality discussed in Section 2.2. We will 
restrict ourselves to the specification model and (part of) the technical mo- 
del; see Section 2.7. The example is the specification of the iterator interface 
I Iterator. The service provided through this interface is that of traversing the 
elements of a finite collection of objects. We distinguish three parties in the con- 
tract: IteratorFactory , Iterator and IteratorUser, whose roles are indicated in 
the UML class diagram shown in Figure 9. 



IteratorFactory 



creates 



Iterator 



-<x- 

llterator 



IteratorUser 



Fig. 9. Iterator Interface and the Parties Involved 



4.2 IDL Level 

The technology-independent IDL-level specification of the iterator interface and 
a possible technology-dependent representation of the interface in Microsoft 
COM IDL are indicated in Figure 10. The former is part of the ‘specification 
model’ and the latter is part of the ‘technical model’ of the iterator interface. 
The technical model should, among other things, define what the precise relation 
between the two representations of the iterator interface is. For a partial answer, 
resolving the question mark in Figure 10, see [2], Chapter 14. The technical 
model will be ignored in the rest of the example. 

The IDL ‘specification’ of llterator raises many questions such as 

— Should the collection of objects be traversed in a particular order? 

— Are duplicates in the collection allowed? 
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HRESULT reset { void ); 
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Fig. 10. IDL Level Specification 

— What happens when all objects in the collection have been traversed? 

— What is the initial state of an iterator? 

— How do iterators come into existence? 

— What if the collection of objects is modified during the iteration? 

It is clear that these questions can only be answered by adding more semantic 
detail to the specification. 



4.3 Summary Level 

The summary level introduces a short informal description for each operation. 
We will not give the complete specification, but restrict ourselves to the operation 
specifications indicated in Figure 11. 



Signature 


Signature 


Signature 


Object next() 
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collection have been traversed, 


to its initial state. 




otherwise false. 





Fig. 11. Summary Level Specification 

Note that the initial state of an iterator, though not specified in the operation 
summaries, could be specified in another part of the interface specification. 



4.4 Model Level 

At the model level a UML model is added; see Figure 12. Note that the UML 
model includes a factory for iterators. It has a single operation that is not part of 
any interface but is used only to model the creation of iterators and specify their 
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Fig. 12. Iterator Model 



required initial state. Whoever creates an iterator should meet the constraints 
specified for the create operation. 

The UML model allows the operations to be described in more accurate 
terms; see Figure 13. The UML ‘role name’ elems in the UML model is interpre- 
ted as a sequence of objects in the Z sense. The notations elems{i) and elems 
are used as in Z to denote the i-th element of elems and the length of elems, 
respectively (sequence indices start at 1). 
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the length of elems. 


false. 





Fig. 13. Model Level Specification 

Note that the summary of create does not specify what the value of elems 
is for the newly created object. This is deliberate, because the value of elems is 
determined by the creator of the iterator. 



4.5 Action Level 

At the action level the effect of operations is specified in ‘structured English’ 
using constructs such as ‘Let . . . ‘Set . . . ‘Return . . . ‘If . . . then . . . else 
. . . ‘While ... do etc. Of course, in this simple example there is not much 
algorithmic detail and no control structures are used; see Figure 14. Bullets and 
indentation are used to make action clauses more readable. The bullets in action 
clauses amount to sequential composition and indentation is typically used in 
control structures to reduce the number of parentheses. 



4.6 Pre &: Post Level 

The pre & post level introduces pre- and postconditions while reducing the role 
of action clauses. The action clauses are typically used to specify the raw side- 
effects of operations only; see Figure 15. Bullets and indentation are used in pre- 
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Fig. 14. Action Level Specification 



and postconditions in the same way as in action clauses to improve readability, 
except that a bullet in a pre- or postcondition amounts to conjunction. The 
standard keyword result is used to denote the result returned by an operation. 
Quotes are used in postconditions to refer to the old values of variables. 
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Fig. 15. Pre & Post Level Specification 

Note that object names introduced in a precondition, action or postcondi- 
tion clause using the ‘Let’ construct, such as it, may be used anywhere in the 
text following the introduction of the name. This way of using object names, 
discussed in [11], also improves readability by avoiding nesting of expressions. 
The traditional use of ‘let’ operators, as in VDM or Z, often leads to nested 
expressions (in order to keep names in scope). 



4.7 Formal Level 

In turning an ISpec specification into a formal specification we should distinguish 
between the structure of an ISpec specification and the contents of that structure, 
i.e. between the ‘branches’ and the ‘leaves’ of the tree structure defined by the 
specification. The structure of an ISpec specification is itself already formal. 
Starting from a pre & post level specification such as the one in Figure 15 there 
should be no reason to change that structure. The contents of the structure, on 
the other hand, may be informal or semi-formal. Some parts are meant to stay 
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informal, such as the summaries of operations, but other parts have to be made 
formal to turn the specification as a whole into a formal specification with a 
well-defined semantics. 

As discussed in Section 3, our intention is to ultimately support different 
formal languages at the leaves of an ISpec specification. For now, we will restrict 
ourselves to the COLD/Z mix used in the prototype ISpec implementation. The 
transformation to a formal specification is not very interesting in this simple 
case, but for completeness we give the formal specifications of the operations in 
ASCII ISpec syntax anyway; see Figure 16. These specifications assume that (in 
another part of the interface specification) the instance variables of objects of 
type Iterator have been formally declared like this: 

elems : seq Object 
index : Nat 



operation Iterator create!) 

summary 

Returns a new iterator, 
pre true 

action let it == new Iterator 
post it. index = 0 
& result = it 



operation Object next!) 

summary 

Returns the next object 
in the collection, 
pre index < card elems 
action modify index 
post index = index ' + 1 

& result = elems (index) 



operation Bool atEnd() 

summary 

Returns true if all objects in 
the collection have been 
traversed, otherwise false, 
pre true 
action skip 

post result = (index = card elems) 



operation void reset!) 

1 summary 

Resets the iterator 
to its initial state. 
I pre true 

action modify index 
post index = 0 



Fig. 16. Formal Level Specification 



5 Related Work 

ISpec is an eclectic approach. It can be seen as an attempt to put together a 
number of well-known and proven ideas and techniques to obtain a practical and 
consistent framework for interface specification. Some of the key inputs to ISpec 
and related approaches are mentioned below. 

ISpec is permeated with the contractual view to interface specification. This 
view is closely related to the idea of ‘design by contract’ [12], with two main 
differences. The first is that ISpec does not focus on design but on the contract 
itself. An ISpec specification is a contract; see Section 2.1. The second is that 
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ISpec contracts are inherently multi-party and not just contracts between a 
caller and a callee (called mini- contracts in ISpec), making them very similar to 
(design) patterns (cf. [9]). 

The multiple levels of formality and detail in ISpec are inspired by the mul- 
tiple levels of abstraction provided by wide-spectrum languages such as VDM- 
SL [10] and COLD [4]. For its expression and assertion language, the current 
version of ISpec uses a combination of language elements from COLD and Z [18]. 

The separation of modelling concerns as incorporated in ISpec goes back to 
the ‘modelling perspectives’ introduced in [3]. Following the terminology used 
in [6] , the conceptual and specification perspectives correspond to the conceptual 
and specification models of ISpec; see Section 2.7. The implementation perspec- 
tive corresponds partly to the technical model of ISpec because the latter deals 
only with the representation of interfaces in the implementation technology used. 

The approach that comes closest to the model-oriented way interfaces are spe- 
cified in ISpec is probably Catalysis [17], though Catalysis is a complete software 
development method, which ISpec is certainly not. The notion of collaboration 
framework in Catalysis corresponds more or less to an interface specification in 
ISpec, and Catalysis ‘types’ correspond to the abstract object classes associated 
with interfaces in ISpec. The main difference is that in ISpec the collaborations 
follow from the specification of the types, while in Catalysis they lead a life of 
their own. (Referring to the terminology introduced in Section 2.4, Catalysis 
uses an impressionistic style of modelling collaborations while ISpec uses an 
expressionistic style.) 

6 Conclusion 

In this paper we have given a survey of the main features of ISpec. Several 
more detailed technical features have not been discussed. They include features 
dealing with aspects of interface specifications such as exception handling, object 
lifetime, asynchronous behaviour, non-atomic operations and multi-threading. 

The ISpec approach, as indicated by the title of this paper, is intended to be 
both practical and sound. The practicality of ISpec is being validated in software 
development projects at Philips, where the approach is used in combination with 
standard CASE tools. The focus in these projects is on the more informal usage 
levels of ISpec. This is in line with the idea of the approach to provide an easy 
entry to the development of better and more rigorous interface specifications. 
An ISpec course is part of the regular technical training program at Philips. 

The formal part of ISpec is currently being used in experiments with au- 
tomatic black-box test generation techniques. This is done by compiling suffi- 
ciently constrained formal ISpec specifications to transition systems encoded in 
^CRL [7] and using the /rCRL tool-set to derive test traces. These traces are 
then used to test implementations of the interfaces against their corresponding 
transition systems. 

As to the ‘soundness’ of ISpec, further research is necessary to develop the 
uniform semantic model that can act as the basis of a language-independent ver- 
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sion of the approach. Other issues that deserve attention are a better integration 
of ISpec and CASE tools, support for timing aspects in interface specifications, 
more guidance with respect to the design of interfaces, and CSpec, the com- 
plementary approach to component specification. A number of these issues are 
currently being addressed in a recently started research project at the Eindhoven 
University of Technology in cooperation with Philips Research. 
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Abstract. This paper presents a global development approach for using 
different formal techniques in a common software development. The un- 
derlying methodology is based on the identification, formalization and 
verihcation of the properties, of the system to be developed, expressed 
in the requirements. The approach we suggest consists in identifying a 
main formal technique to support the whole system specihcation at an 
abstract level and one or several secondary techniques that prove efficient 
for parts of the development. This approach has been put into practice 
in different and distant application domains. The considered application 
domain covered by this paper is human-computer interaction software. 
Keywords: formal techniques, cooperation of techniques, development 
methodology, human-computer interaction. 



1 Introduction 

It is well accepted that the development of safe and secure software requires the 
use of rigorous and mathematically based development techniques. These tech- 
niques shall ensure that the developed software satisfy a set of suited properties 
expressed in the requirements. The use of formal techniques appears as a solu- 
tion for the specification, development, validation and verification of software. 
The processes resulting from these different activities shall be be mastered and 
controlled by the developer. 

In order to organize the use of formal techniques, it is necessary to have 
a methodology or a model that shows when and how one or several formal 
techniques need to be jointly applied. By defining a methodology or a model, 
we mean the definition of a global approach, independent from any particular 
application, that express methodological rules which show when and how one or 
several formal techniques can be used. 

Formal techniques shall allow the capability to perform formal reasoning in 
order to prove that the developed programs satisfy all the properties expres- 
sed in the requirements. Moreover, establishing properties on programs requires 
the definition of formal systems, supported by formal techniques, with formal 
semantics and a proof system. These systems allow to express programs, spe- 
cifications and properties and to prove that specifications and programs satisfy 
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these properties. However, each formal technique is usually applicable and/or 
efficient in part of the development to be achieved only. 

Our claim is that for each program development there is a need to use a formal 
technique in each part of this development where this technique is efficient. 
Proceeding this way leads to : 

- the use of several formal techniques in a common program development, 

- study how the verification of properties, in a given formal technique, can be 

preserved in another formal technique. 

The last point shows that the problem of integrating several formal techniques 
is related to the preservation of the set of properties of a given program from a 
technique to another one and from a development step to another one. Indeed, 
properties are the basis of the choice of a given formal technique allowing to 
prove and to preserve them during the program development. 

The work presented below proposes a methodology which allows to use se- 
veral formal techniques in order to prove program properties and to preserve 
them during the development process. It does not define any new formal techni- 
que but it suggests to use existing formal techniques jointly and to make them 
to cooperate. This methodology has been applied in several application domains 
like: non functional properties of programs [4] [5] [6], human-computer interac- 
tion [13] [12] [10], computer aided design databases [49] [14] [8] [52] etc. 

This paper is structured as follows. Next section gives an overview and a 
chosen classification of formal techniques applied in software development and 
related tools. Section 3 gives the motivations for proposing such a development 
model to integrate formal techniques. Then, section 4 exposes the details of 
the suggested development methodology. It shows criteria to select techniques 
and a sequence of steps to be applied while developing software according to 
the proposed approach. In section 5, we show how this development model can 
be applied for different development approaches, including informal and formal 
ones. Finally, in section 6, this approach is put into practice in the human- 
computer interaction software development area and a conclusion is given in 
section 7. 



2 Formal Techniques 

A set of formal techniques allowing verification, validation, development and 
maintenance of software have been suggested during the last thirty years. They 
support different phases of the software life cycle. 

Formal techniques can be distinguished with different points of view: defined 
goal (development, or verification), underlying proof system (logic based or type 
control based), associated formal semantics (state based semantics, algebraic se- 
mantics), implementation of the proof system (incremental proof system, fully 
automated proof system), approach (a priori or a posteriori) etc. These diffe- 
rent points of view make difficult the choice of one or several formal techniques. 
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Therefore, according to these points of view, several formal techniques taxono- 
mies have been suggested in the literature [30] [51]. In the rest of this section, 
we give a review of formal techniques based on the nature of the proof system: 
incremental or fully automatic. More details about these classifications, formal 
techniques and tools can be found in [7]. 



2.1 Incremental Development Techniques 

Incremental development techniques handle operations that allow to express 
and to refine a given specification into a program, by ensuring that a set of 
properties is preserved and verified. Examples of such operations are refinements, 
transformation rules, tactics, abstract data type implementation, proof steps etc. 
The development is built incrementally by combining these operations. Two main 
categories of incremental techniques can be distinguished: 

- Model oriented formal techniques based on the definition of a set of variables 
defining a state. Logical formulas are used to describe a state and properties on 
this state. A proof system and a set of refinement rules are associated to this 
description. Several techniques belong to this category VDM [17], Z [54], B [2] 
etc. They are distinguished thanks to their semantics (Hoare Logic, Dijkstra’s 
logic etc.). These techniques are a posteriori techniques i.e. the developer exhibits 
the refinement and then he proofs its correctness. 

- Transformational or synthesis techniques, are a priori techniques, which 
usually use algebraic specifications [57], are based on a small set of operations, 
already proved to be correct, that allow to transform a given specification into 
another one. The sequence of operations applications defines a formal transfor- 
mational development. Approaches like the Fold/Unfold transformation system 
of Burstall and Darlington [20], program synthesis of Manna and Waldinger [44] 
were the first approaches to appear, then other ones like [41] [25] [38] [47] [22] 
have been proposed. 



2.2 Model Checking Techniques 

The second type of formal techniques concerns the ones based on automatic 
property verification and program generation. Like for incremental development 
techniques, the distinction between model checking techniques is also based on 
the kind of formal semantics supported by these techniques: 

- The first category is related to the techniques where the model is expressed 
by a transition system showing how state variables evolve. A decision procedure, 
based on a transition system traversal, allows to verify a set of properties, usually 
expressed by temporal logic formulas. These techniques face the state explosion 
problem but abstraction techniques makes it possible to reduce the number of 
states. Examples of such techniques and systems are described in [23] [34] etc. 

- Algebraic semantics gave rise to model checking techniques through rewrite 
systems [28] which use term algebras as models. Moreover, these techniques sup- 
port validation thanks to test generation and verification by property rewriting. 
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- The last category consists in building particular interpreters or analyzers 
which allow the verification of particular properties. This category of techniques 
gathers static analyzers like abstract interpretation [26] [1] or dynamic analyzers 
for tests or formal debugging for example. 

Finally, notice that there exist several behavioral formalisms related either 
to incremental development techniques or to model checking techniques. 

2.3 Tools 

Like for techniques, several tools have been developed and can be classified from 
different points of view: implementation of the proofs (semi-automatic, fully au- 
tomatic), tool capabilities (animation, test, proof, documentation etc.), generic 
or technique dedicated tools etc. We have chosen to classify the techniques ac- 
cording to the last point of view. 

- First, technique dedicated tools are the ones which support a particular 
formal technique. Examples are the Atelier B [55] for B, the VDM-SL [3] lan- 
guage for VDM, SMV [23] for CTL* logic, LUSTRE/LESAR for the LUSTRE 
language, LP [19], the PLUSS [16] language for algebraic specifications, REVE 
or ORME [42] for rewrite systems, etc. 

- The second category of tools supports higher order logics or higher order 
type systems. They are generic tools and they can be “instantiated” to support 
particular formal techniques. Several tools have been developed in this category, 
among them COQ [37], DEVA [56][21], NUPRL[24], NqThm [18], ISABELLE 
[48], LF [35], PVS [45], HOL [32] etc. 

3 Motivation for the Integration of Formal Techniqnes 

The previous brief review of formal techniques and tools shows the existence of 
several different techniques and tools. Moreover, these techniques may be put 
into practice at different levels of the software life cycle. It becomes crucial to 
define a set of methodological rules allowing to use one or more formal technique 
according to the problem to be solved and not according to the deep knowledge 
of one formal technique a developer may possess. In other words, there is a need 
of definition of choice criteria for formal techniques, identification of the deve- 
lopment phases where formal techniques are used and how different techniques 
can be simultaneously used in a common development. Moreover, according to 
the previous descriptions, we discover: 

- the presence of several different techniques and tools, 

- that formal techniques are designed for different purposes: verification, de- 
velopment, analysis, validation etc. 

- that the techniques are self contained and are usually not designed to coo- 
perate with other techniques. This is due to different semantics, different type 
systems, different proof systems, different supported theories, etc. 

- that few methodological rules to use these techniques are defined. They are 
frequently limited to the user manual of the technique or to some case studies. 
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Since formal techniques usually cover only a part of the development of a 
software, it becomes urgent to think to the possibility to define a cooperation 
model where formal techniques will be capable to cooperate in the same soft- 
ware development process, by restricting the use of a formal technique to each 
step where it proves efficient. This is our main claim for defining the following 
cooperative development model. 



4 Our Approach 

For the rest of our description, we will use the word “object program” to mean 
either a program, a specification or a formal model. 

Our approach is a general one. It is capable to support different development 
phases, and particularly: 

- development, if the studied object programs are specifications, 

- property verification, if the studied object programs are models, 

- validation, if the studied object programs are programs or executable spe- 
cifications, 

- maintenance and program understanding, if the studied object programs 
are programs or specifications 



4.1 Selecting a Formal Technique 

Selecting a formal technique is an important step of our approach, based on : 

- the application domain of the problem to be solved, 

- formal knowledge of the application domain. By formal knowledge, we mean 
all the formal notations and techniques used in the application domain, for ex- 
ample, finite elements analysis, interval analysis, formal models for mechanics, 
physics, electronic, signal processing, etc • • • 

- development environment and particularly the existing informal notations 
like OMT, existing software, existing compilers used by the developers, 

- expertise of a developer on a particular formal technique, or a particular 
programming language, 

- and finally, the more important, properties of the software product to be 
developed. 

In fact, the selection of a technique shall be motivated by the nature of 
the problem to be solved, by the application domain and by the properties 
expressed in the requirements. It is not acceptable to enforce the application of 
a given technique nor to extend it, if it is not adapted to the current problem. 
To summarize, a formal technique is chosen if it proves to be the most efficient 
according to the previous points. 
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4.2 Main and Secondary Formal Techniques 

The suggested general model, to integrate formal techniques, identifies two types 
of formal techniques, each of them is selected according to the previous selection 
criteria. 

- The main formal technique (MT) is the one used to express the problem 
and its specifications. It is assumed to be the technique where the maximum of 
properties can be expressed and checked. 

- The secondary formal technique (ST) is a technique selected in order to 
verify properties of the whole system or of a subset of the whole system. There 
may exist several secondary techniques put into practice during one program 
development. Moreover, the use of a secondary technique requires the translation, 
of the whole or of a subset of the system and of the properties to be checked, from 
their expressions in the main technique into their corresponding expressions in 
the secondary technique. This translation shall preserve properties of the system 
from one technique to another. 

4.3 A General Model to Integrate Formal Techniques 

In the following description, figures use continuous arrows to show that the 
carried operations are formally expressed, and dashed arrows to show that the 
carried operations are either formally or informally expressed. The methodology 
to integrate different formal techniques can be described as follows: 

1. Starting from the requirements, identify all the properties and their possible 
formalizations that the final system shall fulfill. Requirement engineering 
techniques from the literature are taken into account at this level [29] [39] 
[46] [36] [40]. We do not address this last topic in our methodology. 

2 . According to the selection criteria identified previously, select a formal techni- 

que to represent a formal expression of the whole system to be developed and 
of the whole or of a subset of the identified properties. The chosen technique 
is considered as the main formal technique (MT). 

3. Let OPp be the object program representing the studied system and Pp the 

set of properties of OPp to be checked. Check the properties Pp expressed at 
step 2: 

3.1. either in the main formal technique according to figure 1, 

3.2. or in a selected secondary technique (ST) according to figure 2. In 
this case, the object program OPp and the set or a subset of properties 
Pp are re-expressed by another object program OPg and another set of 
properties Pg. The verification of the properties Ps in ST must ensure 
that the properties Pp of OPp are preserved by the translation from one 
technique to another. When Pg are proved in ST, the translation of the 
Pg properties from the secondary technique ST into the main technique 
shall ensure that the properties Pp are proved. 

4. If development, refinement or transformation operations on OPp are possible, 

then proceed to the development. We obtain a new OPp and a new set of 
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Fig. 1. Property verification in the main technique. 
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Fig. 2. Property verification in the secondary techniqne. 



properties Pp. The properties of the original OPp shall be preserved by the 
refinement, so, the Pp => Pp formula shall be checked. The development 
operation is achieved: 

4.1. either in the main technique according to figure 3. The properties are 
preserved in the main technique, 

4.2. or in the selected secondary technique according to figure 4. In this case 
P). Ps is formally established and the translation from one formal 
technique to another one must preserve (P' Ps) {Pp Pp). 

5. The sequence of development of step 4 is repeated until the satisfaction of 
the expressed needs and the obtention of the suited system. 

The previous steps describe a methodology allowing to develop a system sa- 
tisfying a set of properties formalized from the requirements expression. In the 
opposite of classical formal development models, this method encourages the use 
of several different formal techniques provided that the properties are preserved 
from one technique to another. Preservation of properties is the basis of method 
integration. This point is discussed in next section. 
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Fig. 3. Development and verification of properties in the main technique. 
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5 Integration of Formal Techniques: Three Derived 
Development Models 

As stated previously, the development model we proposed makes it possible 
to use several formal techniques for the development of a given system. The 
proposed method is based on property verification by the most efficient technique 
and on property preservation from one technique to another one and between 
development levels. It uses formal techniques only. 
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Starting from figure 4, it is possible to derive three different development mo- 
dels where techniques can cooperate. These three models are defined by relaxing 
the continuous arrows or by strengthening the dashed arrows of the suggested 
development model. The following development models are obtained. 

a- The “informal model” is obtained when all the lines are dashed. It means 
that all the steps of development and proof verifications are informally perfor- 
med. 

b- The “formal model” is obtained when all the arrows are continuous. It me- 
ans that translations are formally described and that properties are formally pre- 
served. This model is the complete formal model with integration of techniques. 
However, it is not a trivial task to scale up this model to complex development 
problems. 

c- The “engineering model” is the one obtained by figure 4. This model 
considers that several steps of a development can be formally performed, but it 
accepts that the links between some formal development pieces remain informally 
realized. 

The informal model is out of the scope of our work on formal techniques. We 
did not apply it but we show that it can be derived from our methodology. 

The engineering model approach is close to the ones applied in engineering. 
As example, civil engineers use several formal techniques, like finite elements, 
formal aerodynamic or thermic models etc and they usually do not formally 
relate them but they exploit the results of each model in their global system. 
The engineering model is inspired from this approach. Obviously, ideally, the 
developer tries to reach the formal model where all the steps and the integration 
of techniques are formally stated. 

Finally, as we stated above the engineering model and the formal model have 
been applied in several real case studies using different formal techniques [7]. 

6 Experimentation for Human-Computer Interaction 
Software Development 

The previous methodology has been put into practice in several areas of software 
development. We will review an application of the suggested development model 
and particularly the engineering model for the development of HCI software 
using the B formal technique as the main technique and algebraic specifications 
as secondary technique. 

6.1 The Human-Computer Interaction Application Domain 

It becomes crucial to give the same attention to the development of the human- 
computer interface (HCI) of an application as the one given to the development 
of the functional core of the same application, particularly for critical systems. 
Indeed, control panels in nuclear reactors, pilot interfaces in planes an so on 
require a secure and safe HCI allowing the implementation of all the critical 
user tasks. 



Cooperation of Formal Methods in Engineering 145 



According to our development model of section 4.3, the first step consists in 
an application domain analysis. Like for classical software engineering, several 
notations and models have been suggested for the development of software in 
the human-computer interaction area. We have classified these notations into 
two categories: 

- user notations: are issued from psychologists and ergonomists. They deal 
with tasks and tasks analysis and express the external specifications and the user 
needs. By task, we mean the sequence of basic operations of the human-computer 
interface allowing to reach a particular goal. Examples of such notations are 
MAD [53], UAN [50], etc. 

- developers notations: deal with software development. The human-computer 

interaction area is equipped with several architecture models like PAG [27], 
ARCH [15], etc. and several toolkits like X/Motif, Tcl-TK etc. and several model 
based systems, allowing interface description and code generation like UiM/X 
[31], FUSE [43], [33] etc. 

For all the application domains we investigated, and particularly for human- 
computer interaction, our approach does not consist to propose a new formal 
technique. It suggests to keep all the knowhow of HCI developers and to plug 
formal techniques according to our methodology, described in section 4.3, in 
order to improve the quality of HCI software development and product and to 
formally check HCI properties. 

By HCI properties, the literature, of this application domain, means: 

- visibility: relates to the feedback and information perception by the user, 

- reachability: deals with what can be done with the user interface and how 
it can be done, 

- reliability: concerns the way the interface works with the underlying system. 

Proceeding this way requires a deep study of the application domain on the 

one hand and a good understanding of formal techniques for development and 
verification of software on the other hand. These two points are the two required 
characteristics for a real transfer of formal techniques from toy examples to real 
world applications. 

Let us consider a subset of a study we conducted for the development of an 
air traffic controller human-computer interface. 



6.2 The Case Study 

The very restricted version of the case study we describe consists in a set of 
windows (that may represent planes). Each window can be created (a plane 
entering the control area), resized (focus on the characteristics of a plane), mo- 
ved (to move a plane), destroyed (a plane exiting the control area) and so on. 
Moreover, a mouse is defined in order to perform these operations by direct 
manipulation. 
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6.3 The Main Technique: B 

First of all, we do not review, in this paper, the B technique and its associated 
generalized substitutions semantics. Full details are given in [2], and we assume 
that the B developments given in this paper are understandable by the reader. 

B formal technique is a model oriented technique based on the description, 
in an abstract machine, of a set of state variables, invariant properties on these 
variables and a set of operations which modify the values of the state variables. 
Moreover, abstract machines are combined by programming in the large ope- 
rators and can be refined from an abstract level representing specifications to 
the programming language concrete level. The Atelier B [55] tool, we have used 
in our experiments, allows an automatic proof obligation generation and proof 
obligation checking. 

According to the selection criteria given in section 4.1, the choice of B as 
main technique is motivated by: 

- its capability to support either programs, specifications, proofs and deve- 
lopments, 

- the possibility to design and to control the development incrementally, 

- supporting modular decomposition, 

- the availability of a tool, 

- and finally, may be the most important, the adequacy of the B specification 
decomposition with the informal developer notations used in HCI development 
context. Indeed, the ARCH model, we have used, decomposes the whole ap- 
plication into a set of modules that are positioned on an arch going from the 
functional core on the left to the toolkit on the right with intermediate modules 
in between. 

6.4 Specification 

As an illustration, we have chosen to show part of the specification of the mouse 
management. A mouse is defined by attributes: x and y positions on the screen, 
a state showing that it is either up, down or clicked and a Boolean attesting that 
the mouse is actually created by the system, in B, these attributes are represented 
by the functions xjposjmouse, y-posjmouse, mousestate and mouse -creation. 
The mouse is created in a set whose number of elements shall be less or equal 
to 1. 

Two operations related to the mouse management are described: 

- createjmouse allows to create a mouse of type MOUSE and adds it to the 
set mouse at a predefined coordinate with an up state. Its B specification is 
given by: 

mm i — createjmouse = 

PRE 

mouse ^ MOUSE 
THEN 
ANY 

tt 
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WHERE 

tt G MOUSE — mouse 
THEN 

mm := tt || 

mouse := mouse U {tt} || 
xjposjmouse(rnm) := xjmouse He fault || 
yjposjmouse{mm) := ymiouse He fault || 
mouse -stateftt) := up || 
mouse -creationftf) := TRUE 

END 

END 



- movejmousejwithHrag allows to move a mouse to a new position with a 
state at down. This operation requires that the new xx and yy coordinates are 
in the screen limits and that the mouse state is down. Its B specification is given 
by: 

movejmousejwithHrag{mm,xx,yy) = 

PRE 

mm G mouse A 

XX G NAT A XX G l..max-mouse-wide A 
yy G NAT Ayy G l..maxjnouseJiigh A 
mouse -state{mm) = down A 
mouse -creationimm) = TRUE 
THEN 

Xjposjmouse{mm) \= xx 1 1 
y_posjmouse{mm) := yy 

END 

Safety properties are expressed by an invariant property. The INVARIANT 
B clause of the previous specifications contains the following property: 

Vmm G mouse, (x-posjmouse{mm) G l..max-mouseJwideA 
y jpos jmouse{mm) G \..maxjmouseJiigh) 

It states that each window (plane) of the screen is reachable(meaning that each 
plane in the control space area is reachable by the air traffic controller). This is 
one of the safety properties related to reachability and reliability properties, in 
human-computer interaction classification, we have checked. 

6.5 Refinement 

Refinement from specifications to code is conducted in two steps. 



Refinement of Operations. The two previous operations are refined to : 

- creatc-mouse by introducing the begin end bloc, the local variable VAR, the 
sequence and the if then else conditional substitutions. 
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mm i — createjmouse = 

BEGIN 

VAR 

tt IN tt £ MOUSE — mouse 
IE 

{mouse ^ MOUSE) 

THEN 

mouse := mouse U {tt}; 

X-pos-mouse{mm) := x -mouse -default ; 
y-pos-mouse{mm) := y -mouse -default ; 
mouse -state{tf) := up ; 
mouse -creation{tt) := TRUE ; 
mm := tt 

END 

END 

- move-mouse-with-drag by introducing the begin end bloc, the sequence and 
the if then else conditional substitutions, 

move-mouseJwith-drag{mm,xx,yy) = 

BEGIN 

IF 

mm £ mouseA 

XX £ NAT A XX & 1.. max -mouse -Wide A 
yy £ NAT Ayy € 1.. max -mouse -high A 
mouse -state{mm) = down A 
mouse -creation{mm) = TRUE 
THEN 

X-pos-mouse{mm) := xx] 
y-pos-mouse{mm) := yy 
END 

END 

For the refinement of operations, all the proof obligations were automatically 
generated and checked by the automatic prover of Atelier B. At this stage, we 
reach the programming language level, except that data are still abstract. 



Refinement of Data. When the previous refinement is achieved, two problems 
arise: 

- the code reached by the previous refinement does not allow reusability of 
the code of the existing toolkits. Indeed, HCI software development is based on 
pre-existing toolkits implementing basic operations to manage mouse, windows, 
interactions and so on. It is not acceptable, for HCI software developers to design 
a new toolkit, at each development, 

- the implementation of abstract data types describing sets and selectors 
by the corresponding pre-existing implementation abstract machines of Atelier 
B, generates a set of unreadable proof obligations, making the implementation 
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phase impossible in B. To solve these two problems, we had to use two secondary 
techniques: 

- reverse engineering techniques in order to synthesize abstract machines 
representing toolkits i.e. B specifications to represent toolkit software. We have 
practically described a set of abstract machines to represent, in B, a subset of the 
Tcl-Tk toolkit. This process is facilitated by the nature of the software describing 
this toolkit: a set of modules with attributes and functions. The synthesis of an 
abstract machine followed the existing module decomposition. Nevertheless, the 
difficulty we faced is the extraction of the relevant properties to be expressed 
in the specifications. This methodological point shall be solved by HCI software 
developers. 

Therefore, it became possible to refine operations of our problem specificati- 
ons to reach Tcl-Tk code through a call to the B operations contained in the B 
abstract machines which abstract Tcl-Tk operations, 

- algebraic techniques to implement abstract data types (ADT’s) by concrete 
data types (CDT’s). We have used the algebraic refinement of ADT’s in order to 
implement sets by lists and selectors by introducing records. Moreover, thanks 
to the formal algebraic refinement technique, we formally ensured abstract data 
types implementation correctness. This work consisted in defining representation 
functions for the empty and add sets constructors by the nil and cons lists 
constructors. 

6.6 Domain Oriented Conclusion 

In the context of human-computer interaction software development, the use 
of the B technique gave several interesting results. This approach handles all 
the development steps from specification to code generation, property verifica- 
tion and supports an incremental controlled development. Several studies follo- 
wing the proposed development model validated this approach at a large scale 
[12][13][11][10][9]. 

The proposed approach does not suggest any new technique nor the extension 
of an existing technique. Moreover, it takes into account the existing notations 
for application domains (architecture model ARCH) and reuses existing software 
(Tcl-Tk toolkit). It shows that formal techniques are plugged to existing deve- 
lopment models and notations and are put into practice at every place where 
formal verification is required. 

Moreover, the developed approach gave rise to several perspectives like: 

- considering other notations of the human-computer interaction application 
domain. Indeed, it is necessary to take into account user notations and tasks 
analysis models describing the HCI external behavior, 

- combining formal validation techniques in order to be capable to test B 
specifications for implementing user tasks. A current work using the EXPRESS 
formal specification language is being conducted. It consists in translating B 
specifications into EXPRESS data models. In EXPRESS all the B operations 
are expressed by state transformations (from the starting state to the final state) . 
Each state is an EXPRESS entity with attributes and logical constraints. An 



150 



Y. Ait-Ameur 



operation is full defined by two state entities (start and final) . Instances of state 
entities describe test cases. It is planned to publish this work later [9]. 

- combining model checking techniques encoding temporal logics with incre- 
mental development techniques in order to prove liveness properties representing 
most of the users tasks and reachability properties in human-computer interac- 
tion, 

- and finally, define a reverse engineering methodology in order to get libraries 
of specifications (to represent existing toolkits specifications) with the relevant 
operators and properties. 

6.7 Use of the Integration Model 

The suggested solution for studying the development of HCI software follows the 
development model, precisely the engineering model, we proposed in section 4.3. 
Properties like the one of section 6.3 have been identified, formalized, proved 
and preserved. The development followed: 

- step 4.1. for refinement of operations and property, verification and preser- 
vation, expressed in the unique B main technique according to figure 5, 
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Fig. 5. Development and verification of properties expressed in B. 



- step 4.2. for reverse engineering of toolkit specifications and implementation 
of ADT’s by CDT’s using algebraic formal techniques as secondary techniques. 
The translation of ADT’s specifications from B specifications to algebraic spe- 
cifications has not been formalized. This step is assumed to be handled by the 
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developer, and its formalization is not free from a development cost point of view. 
However, if required, its formalization is possible. In this case, we are using the 
engineering development model according to figure 6. 
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Fig. 6. Development and verification of part of the properties in the secondary tech- 
nique. 



The engineering development model proved useful for integrating different formal 
software development techniques. It showed that it is possible to use different 
formal techniques jointly avoiding heavy proof steps to formally establish how 
these techniques cooperate. However, if these proofs are required, then the coo- 
peration shall be formalized according to the complete formal model derived in 
section 5. 

7 Global Conclusion 

This paper has shown a development model where one or several formal techni- 
ques can be integrated in order to support formal development and verification 
of programs. The underlying methodology showed that: 

- it supports complete or incomplete formal developments thanks to the for- 
mal and to the engineering models respectively. 
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- property based reasoning allows to guide software development process and 
to select a formal technique, 

- properties of specifications are preserved form one step to another one even 
if the development is not completely formalized, 

- several techniques can be put into practice in a common software develop- 
ment. Each technique is chosen with respect to the properties to be checked and 
to its efficiency to handle these verifications and to solve the current problem. 

The development model we have suggested shows that even if an universal or 
global formal technique does not exist, the use of several techniques, in an orga- 
nized manner using a precise methodology and the application domain knowhow, 
leads to the encoding of non trivial and complex program developments. 

However, notice that the choice of techniques and the order of application of 
these techniques remain one of the hardest tasks of the software developer and 
shall take into account all the expertise, notations and knowhow related to the 
application domain. 

Finally, obviously the main perspective related to the definition of our de- 
velopment model consists in formalizing the greatest number of links or bridges 
between formal techniques. Regarding the different figures illustrating our me- 
thodology this perspective leads to transform all the dashed arrows of figure 
4 into continuous arrows. Two approaches allowing to formalize links between 
techniques are identified. Either by, 

- translating one formal technique into another one and prove the correctness 
of this translation, - or by translating the two formal techniques into a third one, 
mainly a higher order logic or a higher order type system. The third technique 
is used to prove equivalence. 

Moreover, our claim is that the formalization of these links between techni- 
ques shall be done according to the application domain where the development 
model would be put into practice. 
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Abstract. In this paper we point out the potential of software enginee- 
ring methods in developing control systems as well as in deriving the 
control software for them. The general strategy for such a development 
comprises two phases. An initial system-level specification models both 
the physical environment and its control software within the same state 
machine oriented view of the system. The control software can be then 
extracted from this specification and further refined via correctness- 
preserving steps. The design strategy is intended for the development 
of control system components and combines the UML statechart dia- 
grams and the OO-action system formalism in a novel way. We show the 
applicability of the method using the Production Cell case study. 



1 Introduction 

Component-oriented design consists in assembling new systems from existing 
components, as well as in constructing components dedicated to the assemb- 
lage. The software component term has been coined about three decades ago 
as a logical solution for the software crisis [18], by analogy with plug-and-play 
inter-operability available to producers and customers in other engineering fields. 
Thus, in 1968, Mcllroy pointed out that mature industrial engineering builds on 
components and so should software engineering [18]. Component-oriented pro- 
gramming is still not very spread, but the experience of three decades is now 
used to ground it as a fundamental software construction method [25]. 

A component is essentially a black box implementing a set of services pro- 
vided that a required set of context dependencies are available. A component is 
thus an abstraction over the space of services of a system. The services that a 
system has to perform are partitioned into groups, each group of services being 
implemented by a component. Components interact with each other by using the 
provided services, and thus, an important issue regarding a component-based sy- 
stem consists in the interactions among the participating components. Rather 
than designing systems using existing components, in this paper we focus on 
correctly developing the components and on designing their interaction patterns 
in the context of control systems. 

A control system component usually consists of hardware and software parts 
that collaborate for achieving a set of services. Good integration techniques for 
constructing control systems are consequently required from this very basic level. 
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However, in the context of control systems there are also some other important 
integration issues to handle. 

Control systems are typically embedded into complex assemblies. On one 
hand, the inherent complexity of a control system requires some scalable en- 
gineering methods for modelling purposes. Graphical and diagrammatic specifi- 
cation methods, which yet often lack a formal basis, have turned out valuable 
in this respect. On the other hand, the correct functioning of the control system 
with its complicated interrupt handlers is critical, requiring a formal approach 
to ensure dependability. Thus, in order to model control systems, formal and 
informal design methods have to be integrated. 

In this paper we use the UML (Unified Modeling Language) [7] as the in- 
formal specification method. UML becomes the ‘de facto’ standard method for 
developing object-oriented software, providing a collection of diagrams for spe- 
cifying, developing, and maintaining software. We focus on UML statechart dia- 
grams, used to describe the behaviour of active objects, as active objects are 
a suitable model for control system components. For the formal specifications 
we use the 00-action systems framework [6], an object-based approach to the 
design of parallel and distributed systems. 00-action systems have their roots in 
other state-based formalisms like action systems [3] and UNITY [II]. We chose 
this formalism as it allows us to concentrate on the collaborative behaviour of 
the system components first and develop the details of the system later, when 
the overall functionality is specified. In this way we obtain a level of abstraction 
that is so high that it is easy to reason about the behaviour of the system and 
yet detailed enough so that the systems can be developed all the way to their 
implementations within the same framework. The use of these two specification 
frameworks, informal and formal, for the development of control systems poses 
a couple of integration questions. 

First, we need to address the integration of a diagrammatic specification me- 
thod with a formalism. This problem has already been investigated, indicating 
that formalisms are in general not scalable nor easy to use, thus requiring a 
manageable complement [20]. Integrating diagrams with a formalism has been 
shown as viable, for instance in [19]. Moreover, as UML is widely used for soft- 
ware construction, defining a formal semantics for its different diagrams became 
quite important [13]. This is usually achieved via different formalisms and ad- 
dresses a diverse range of diagrams, see for instance [1,21,9]. There has also been 
work towards using different techniques, formal and informal, to model different 
aspects of a system design and to show that these techniques provide a consi- 
stent view of the system under construction [8,26]. In this paper we follow the 
latter approach and use the UML statechart diagrams to give an informal and 
basic specification for the control system under construction. The formal spe- 
cification, written using the 00-action systems formalism is usually difficult to 
initiate. Here it is created from the statechart diagrams. At this stage, both spe- 
cifications provide the same view upon the control system under development. 
The formal specification is then improved via a number of refinement steps. 
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Second, the UML statechart diagrams are an event-based method of spe- 
cification, while the 00-action systems are a state-based formalism. For using 
both of them in the development process of a control system, we have to find 
a suitable way of integrating them. In this paper we concentrate on this second 
aspect of integration. The ability of 00-action systems in modelling events and 
event-based mechanisms is based on a common feature shared by them and the 
UML statechart diagrams. Namely, both frameworks are models for active ob- 
jects, i.e. objects having an autonomous behaviour. Given this basic property, 
the two frameworks can be integrated and used together for specifying control 
systems components. The initial development stage is based on UML statechart 
diagrams, that are then translated to an 00-action systems specification. 

00-action systems are intended to be stepwise developed from a high-level 
specification to an implementation via correctness-preserving refinement steps 
relying on a solid mathematical foundation, the refinement calculus for action 
systems [3] . Rather than embody all the requirements in the initial 00-action sy- 
stem specification, we introduce the requirements in successive refinement steps. 
Although refinement is used normally as a way of verifying the correctness of 
an implementation w.r.t. a specification, it is used here as a way of structuring 
the requirements such that they are easier to validate. This technique was used 
before in [10]. 

Hence, we make the following contributions: 

— We develop a construction method for the components of control systems. 

— We point out the potential of software engineering methods in developing 
control systems components. 

— We argue for the suitability of integrating event-based UML statechart dia- 
grams and state-based 00-action systems formalism. 

To make the presentation concrete, we will throughout this paper apply our 
method on a part of the Production Cell example, a well-known case study [22] 
on control systems that has been used as a sort of a bench mark for formal 
methods. 

We proceed as follows. In Section 2 we present our view on the development 
of control systems. The UML statechart diagrams form the focus of section 3. 
Section 4 describes the formal approach on control systems, represented by 00- 
action systems. In Section 5 we present our case study on the Production Cell, 
concentrating on two of its control system components. Section 6 is dedicated 
to refining the specification of a control system component, by emphasising its 
internal decomposition. We conclude in Section 7 with some final remarks. 



2 The Development of Control Systems 

A control system is composed from a physical environment called plant, that 
is usually coordinated by a software system, called controller. The controller 
is informed upon the state of the plant using observer devices called sensors 
and commands the update of the state of the plant using devices that perform 



Developing Control Systems Components 159 



the update, called actuators. The sensors and the actuators are specific control 
entities. They are also used by the plant, that observes the updates made to 
its state by the actuators and modifies accordingly the values displayed by the 
sensors. This pattern of communication between the plant and the controller, 
using sensors and actuators, is illustrated in Fig. 1 and was also used in [23]. It 
is specific to a control system, and so is the logical decomposition of a control 
system into entities like plant, controller, sensors, and actuators. 




CONTROLLER PLANT 



Fig. 1. Structure of the control system specification 



As we intend to build a control system from components, the strategy for de- 
veloping it comprises two main phases. Initially, the control system components 
are identified. At this stage, the main purpose is to capture the essential func- 
tions and properties of the overall system into the participating components and 
also to determine the communication patterns between the components. Follo- 
wing this phase, the focus moves from the system as a whole to each component 
of the system. The specification of each component has to be stepwise refined 
until it reaches a structure as depicted in Fig. 1. The process as a whole has 
to be provably correct and according to the initial specification of the control 
system to develop. 

For expressing this rather general strategy we work in this paper with two 
specification frameworks: the UML statechart diagrams and the 00-action sy- 
stems. The former is used in the first phase of the system to ease the specification 
of a control system with its complicated reactive structure. The latter is also used 
in the first phase for making the statechart diagrams specification precise, but 
its potential is fully exploited in the second phase of the development strategy. 
An 00-action system specification can be verified to fulfil certain goals and also 
stepwise refined, hence ensuring the correctness of the developed system. 

Therefore, in this paper we focus on the development of control system com- 
ponents. The following section presents the initial specification phase for such 
components using the informal, event-based approach of the UML statechart 
diagrams. 
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3 Graphical Specification of Control Systems 
Components 

The Unified Modeling Language (UML) [7] is a powerful and expressive dia- 
grammatic notation used for specifying object-oriented software systems. UML 
is focused on the conceptual description of a system and its basic building blocks 
include diagrams, used to describe different views or aspects of a system. A dia- 
gram is essentially a projection of the system. The elements of the system under 
development may appear in all or only in few diagrams. For instance, use case 
diagrams describe a functional view of the system under development, while the 
class diagrams present the problem domain of the system, emphasising its object- 
oriented structure. In this paper, we focus on statecharts diagrams, that show the 
internal behaviour of class instances (objects), revealing an event-driven view of 
the system. 

Statecharts were introduced by Harel [14] and further developed since [5, 
24]. Statechart diagrams, the UML’s approach [7] to Harel’s statecharts show 
the state machines of objects. A state machine is a behaviour that specifies 
the sequences of states an object goes through during its lifetime, in response 
to events, together with its responses to those events. A state is a condition 
or a situation during the life of an object. During a state, the object satisfies 
some condition, performs some activity, or just waits for some event. An event 
is a specification of a significant occurrence, that in a state machine can trigger 
some transition. Events can be asynchronous (like signals) or synchronous (like 
method calls). A transition is fired if, besides the occurrence of its significant 
event, a guard condition holds. While the object is in a transition between states, 
some action can also take place. 

Statechart diagrams, useful in describing objects whom behaviour depend on 
their past, prove useful as models for control system components. A statechart 
diagram is intended here to model the behaviour of one component. However, 
due to the event-based approach of this specification method, a collection of dif- 
ferent statechart diagrams will model the behaviour of several components. The 
communication between them takes place by sending and receiving events. Even 
though control systems combine hardware and software parts, at this component- 
oriented level we apply a software engineering technique (UML) to specify them. 
Later on, the hardware parts will be detached from each component. 

The question to be answered at this level refers to the suitability of the 
statechart diagrams in describing the components interaction with each other. 
In general, a component implements some public interfaces that produce some 
result when certain inputs are provided. This mechanism is not hindered by 
the event-based approach of the statechart diagrams method, but modelled in 
the latter by sending and receiving events. A received event can embed the 
input parameters. Upon receiving it, a transition can be fired, possibly some 
action can take place, the entity might go through a set of states, and eventually 
some other event is sent, embedding the result parameter. The question posed 
is thus technically answered. However, an interesting aspect can be observed 
in this context. The component-orientation is an engineering strategy based on 
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encapsulation, since each component is seen only via the interfaces (services) 
that it is able to provide. A statechart diagram, on the other hand, is breaking 
this encapsulation by essentially showing the internal sequence of states that 
component goes through, in order to provide different services. 

The explanation of this duality stands in the fact that these two sides of 
a component represent two phases of the engineering process. The components 
of interest are discovered in the first phase, based on the services they should 
provide. Following this phase, the development of each component starts by de- 
termining its statechart diagram. This graphical representation is the skeleton 
of the component. The approach we take for constructing control systems is 
component-based, but in this paper we focus on the development of their com- 
ponents. The statecharts are useful as they allow us to focus on one component 
at a time while still being able to model interactions via sending and receiving 
events. 

As an example, consider the Production cell that is a control system whose 
task is to forge blanks. However, the blanks are supposed to be fed in by some 
component, transported by other component, pressed by another one, transpor- 
ted again and finally removed from the system by yet another component. For 
clarity, we focus in this paper on the pressing component, called press and on 
its interaction with the transporting component, called robot. The robot, besides 
transporting blanks and interacting with the press, is also interacting with other 
components. We will show these interactions, but do not develop them later. 

By establishing the components, the system is specified in ‘breadth’. Next, we 
can focus on each component of interest, thus specifying the system in ‘depth’. 
The press and the robot component have the statechart diagrams as in Fig. 2 
and Fig. 3 respectively. These diagrams are based on the following specifica- 
tion [22]: ‘The task of the press is to forge metal blanks. The press consists of 
two horizontal plates, with the lower plate being movable along a vertical axis. 
The press operates by pressing the lower plate against the upper plate. The press 
has three positions. In the lower position, the press is unloaded by arm 2 (of the 
robot), while in the middle position it is loaded by arm 1 (of the robot). The 
operation of the press is coordinated with the robot arms as follows: (1) Open 
the press in its lower position and wait until arm 2 has retrieved the metal plate 
and left the press. (2) Move the lower plate to the middle position and wait 
until arm 1 has loaded and left the press. (3) Close the press, i.e. forge the metal 
plate. This process is carried out cyclically. The robot has two orthogonal arms. 
Each arm can retract and extend horizontally. The end of each arm is fitted with 
an electromagnet that allows the arm to pick up metal plates. The robot’s task 
consists in taking metal blanks to the press and transporting forged plates from 
the press. The order of the rotation operations the robot has to perform is as 
follows. (...) The robot rotates counterclockwise until arm 2 points towards the 
press. Arm 2 is extended until it reaches the press, then it picks up a forged 
metal plate and retracts. (...) The robot rotates counterclockwise until arm 1 
points towards the press. Arm 1 extends, deposits the blank in the press and 
retracts again. Finally, the robot rotates clockwise towards its original position. 
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and the cycle starts again.’ The complete specification of the Production Cell 
case study is given in [22]. 



^Receiving]- 



Received A RobotSafe 



Pressing 



Moving To Delivery^ 



(^Moving To Recei^^ 



Delivered A RobotSafe 



-(^Delivering^ 



Fig. 2. Statechart Diagram for the Press Component 



The diagrams in Fig. 2 and Fig. 3 are rather simple statechart diagrams. 
The initial state of each component is shown by an arrow coming from a filled 
circle and the activity performed within some states is preceded by the key 
word ‘do/’. The states of the robot containing some activity are the states in 
which it interacts with the press. The rest of the states are only mentioned. 
Since the robot and the press are supposed to synchronise when exchanging 
blanks, the robot advances to an interaction state only when it received the 
event PressReady. In these interactions, the press is passive, so it advances to 
its new states only when it receives an event acknowledging that the blank has 
been processed {Received or Delivered) and the correspondent robot arm is safely 
retracted {RobotSafe). 



, 5 I ^ Moving To Feed ] ^ Feeding ] ^ Moving To Unload] 

do/ LoadPress ' 



PressReady 



PressReady 



f Moving To Load f Depositing}^ fMoving To Deposit}^ I ^ 

V s ; ^ y ^ ^ 6 1 ; | ^nloadPress 



Fig. 3. Statechart Diagram for the Robot Component 



Statechart diagrams are an intuitive model for reactive components in a con- 
trol system. These components usually work cyclically, expect events to whom 
they react and send events to other components. Thereby, the diagrams above 
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are a simple means for expressing collaborations in a control system, at an in- 
formal level. The statechart diagrams can also express more complex behaviour 
in terms of more details of the interactions or of the internal behaviour of the 
components. Yet, on one hand, when concentrating on components and the ba- 
sics of their interactions, such a pattern of specification as illustrated in Fig. 2 
and Fig. 3 suffices. On the other hand, in order to specify the components pre- 
cisely and systematically, the statechart diagrams (as their statecharts prede- 
cessors [14]) are too informal, as revealed in many sources [15,16,17]. Moreover, 
they are not equipped with refinement techniques, thereby one cannot ensure 
the consistency of simple skeleton diagrams like the ones above with other, more 
complex diagrams of the same component. One solution consists in using the sta- 
techart diagrams together with a formalism that has these features built-in. Such 
a formalism should also be compatible with the statechart diagrams. We present 
in the following section one such formal framework, the 00-action systems. 

4 Formal Specification of Control System Components 

In this section we describe the 00-action systems formalism, show how it relates 
to the component-based design of control systems, and also describe the common 
ground that enables its use together with the statechart diagrams for specifying 
control systems components. 

An 00-action system consists of a finite set of classes, each class specifying 
the behaviour of objects (class instances) that are to be created and executed 
in parallel. Let Attr be a fixed set of attributes , each attribute being associated 
with a nonempty set of values, the type set of the attribute. Let further CName 
be a fixed set of class names and OName a set of valid names for objects. We 
also consider a fixed set of object variables OVar assumed to be disjoint from 
Attr. The valid values for object variables are the names for objects in OName. 

A class is a pair < c,C >, where c € CName is the name of the class and 
C is its body, i.e., a collection of data (attributes and object variables), services 
(methods) and behaviour (actions to be executed by the instances of the class): 

C — I [ attr X : = xo 
obj n : = riQ 

meth mi = Mi ; ■ • ■ ; m^ = Mh (1) 

do A od 

]l 

The class body consists of an action A and of three declaration sections. The 
section attr declares the local attributes x, used only by the instance of the 
class itself. The section obj of object variables n declares a special kind of 
attributes local to an instance of the class. They contain names of objects used 
for calling methods of other objects. The attributes and the object variables are 
initialised to the values xq and no, respectively. We assume the lists x and n 
pairwise disjoint. The section meth of methods mi = Mi describes procedures 
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of an instance of the class. They can be called by actions of the object itself 
or by actions of another instance of possibly another class. Methods consist of 
a header rrii and a body Mi, the bodies being actions. The action specified in 
the do ... od loop of a class is a description of the autonomous behaviour that 
an instance of this class has at run time. An action can refer to the attributes 
and object variables declared within the class or can contain method calls of the 
form n.m to methods declared in another class or itself. The actions are defined 
by a grammar presented in detail in [6]. An action can model statements that 
always deadlock, stuttering statements, multiple assignments (: =), conditional, 
sequential (;) and non-deterministic (|) composition of actions, method calls or 
guarded commands of the form & — >■ A, where & is a predicate and the action 
A is executed only when its guard b evaluates to true; in this case the action is 
said to be enabled. All these actions have a well defined semantics [6], in terms 
of the weakest precondition predicate transformers in the style of Dijkstra [12]. 

An 00-action system O consists of a finite set of classes 

e> = {< Cl, Cl >,...,< c„,C„ >} (2) 

such that actions in each Ci or bodies of methods declared in each Ci do not 
contain constructor methods referring to class names not used by classes in O. 
Every object has a local state. An object, when created, chooses enabled actions 
and executes them. If there is more than one enabled action in any given state, 
the choice between them is non-deterministic. Actions are taken to be atomic. 
Because of this, actions within an object operating on disjoint sets of attributes 
and object variables can be executed in parallel. Moreover, enabled actions of 
different objects can be executed in parallel as they are operating on disjoint sets 
of attributes. Computationally, an 00-action system is a parallel composition 
of many objects, each of them representing an instance of a class [6]. 

The interaction between objects is by calling methods of other objects. Me- 
thod calls are usually prefixed by an object variable. If such a prefix is missing, 
the called method should be declared in the calling object. Calls to methods of 
other objects are possible only if the calling object has a reference, i.e. an object 
variable, to the called object; this models the encapsulation mechanism. The 
meaning of a call on a method is determined by the substitution principle: let A 
be an action in an object oi calling a method m in some object 02 . Following 
the call, the body of the method is substituted for each method call. Hence, the 
action A becomes A[o 2 .M /n.m] where n is the object variable in o\ containing 
the reference to 02 and M is the body of the method m in the object 02 . The 
action A is then executed jointly by the objects Oi and 02 in an atomic fashion. 
Here we assumed that the method m is parameterless. For a similar principle 
including parameters, the reader is referred elsewhere [3]. 

Components. In this framework of 00-action systems we define the notion of 
component as follows. Let Comp be a fixed set of component names. A compo- 
nent is a class-based specification using an 00-action system O as in (2). The 
name O G Comp. The interaction between components is modelled via calls to 
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methods declared in a class body of the same or some other component (00- 
action system). In the latter case, holding a reference only to the name of the 
component is enough, provided that the names of the class methods in a compo- 
nent are unique. We extend an initial requirement and consider as valid values 
for object variables the names for objects in OName and also the names for 
components in Comp. 

Therefore, we can specify interactions among components using the 00- 
action systems formalism. By doing so we get a number of advantages, like 
an object-oriented approach to components and a programming language-like 
specification for them. These features provide an easier grasp for programmers. 
Moreover, by using this approach we get another important benefit: we can 
focus on the design of one component at a time. This independent development 
of components is an essential feature of the component-based paradigm. The 
methods of the classes in a component as described above model the interfaces 
provided to the exterior by that component. The object variables, holding the 
names of the components of interest, model the dependencies required by the 
component from its context. Thus, the naming mechanism offers a simple method 
of communication between components. 

Refinement. An important feature coming with this formalism consists in the 
possibility of stepwise refining the component specifications. The refinement as a 
process is seen as transforming a specification O into a specification O' when O 
is abstract and non-deterministic and O' is more concrete, more deterministic, 
and preserves the functionality of O. A particular method of refinement consists 
in adding on top of one specification new attributes and methods in a way that 
preserves the old behaviour but makes the new one also possible. This type of 
refinement is usually referred to as the ‘superposition’ refinement and is discus- 
sed formally elsewhere [4,6]. In this paper we take a rather informal view of it, 
focusing on the engineering process as a whole. We will thereby check whether by 
adding new data or services the old behaviour is still satisfied. The following sec- 
tion presents an example of this strategy, by refining the interaction mechanisms 
between the press and the robot component, as described above. In section 6 we 
show that by using 00-action systems mechanisms like superposition refinement 
and parallel composition some other type of refinement to the specification of 
an individual component can yet be performed. 

Integration with Statechart Diagrams. In order to refine the interaction 
patterns between components, an initial 00-action systems specification is re- 
quired. Like all the formal frameworks, the 00-action systems formalism lacks 
an intuitive and easy-to-use method for constructing an initial specification. In 
this respect, the integration with a diagrammatic method of specification would 
bring this advantage for the 00-action systems framework. 

The UML statechart diagrams can be seen as the skeleton of a component 
and translated into an 00-action systems specification. This operation embeds 
an important result, namely the integration of an event-based framework with 
a state-based one. The availability of this process is due to the fact that both 
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the statechart diagrams and the 00-action systems are models for active ob- 
jects. Thus, the entities modelled by these two methods have a local state and 
autonomous behaviour. This autonomous behaviour is modelled in the case of 
00-action systems with the action loop in the class bodies, while in the case of 
statechart diagrams with the transition of an entity from a state to another. The 
latter mechanism can be naturally modelled by a state attribute of a class in an 
00-action systems specification. The type set of this attribute is formed by all 
the states that the object can have in the statechart diagram and its value is 
modified by actions in the action loop of the body of the class. The modifying ac- 
tions model the transitions from state to state. If these transitions are triggered 
by some events, the latter are modelled by predicates or method calls, depending 
on whether the triggering event is local to the component or not, respectively. 
In the latter case, the method has a boolean result parameter that is function of 
the state of that component. The component requiring this triggering event for 
firing its transitions will keep an object variable to that component name, for 
being able to call the method of the latter. These principles are applied in the 
following section on the statechart diagrams from Fig. 2 and Fig. 3. 

5 Case Study 

In this section we apply the translation principles presented in the previous sec- 
tion on the Production Cell example. We also apply the superposition refinement 
principle presented in Section 4 for making the translated specification precise. 

The statechart diagrams in Fig. 2 and Fig. 3 are translated into the compo- 
nents Press = {< Pr >} and Robot = {< ro, Ro >}. In the component Press 
the class body Pr has a single attribute state that models the current state of 
the press and similarly, the component Robot has the class body Ro where the 
single attribute state models the current state of the robot. 



Pr = |[ attr state : = Receiving 
obj rr : Robot 
meth Ready = ... 

do state = Receiving A Received A rr.Safe — >■ state : = Pressing 
I state = Pressing — >■ state : = MoveToDeliver 
I state = MoveToDeliver — ^ state : = Delivering 

I state = Delivering A Delivered A rr.Safe — ^ state : = MoveToReceive 
I state = MoveToReceive — >■ state : = Receiving 



od 

]| 



Both components require some information from each other in order to func- 
tion, modelled in Fig. 2 and Fig. 3 with the events RobotSafe and PressReady, 
respectively. We model this requirement in the 00-action systems specification 
with two methods. Safe and Ready, declared in the Robot and Press compo- 
nents, respectively. These methods return a boolean result parameter that is 
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function of the respective component state. In order to access these methods, 
the Press component maintains an object variable rr to the Robot component 
and similarly, the Robot component maintains an object variable pp to the Press 
component. The events Received and Delivered in Fig. 2 are modelled with two 
predicates with the same names, while the activities LoadPress and UnloadPress 
in Fig. 3 are modelled with some actions denoted by the same names: 



Ro = |[ attr state : = Loading 
obj pp : Press 
meth Safe = ... 

do state = Loading LoadPress ; state : = MoveToFeed 
I state = MoveToFeed — > state : = Feeding 
I state = Feeding — >■ state : = MoveToUnload 
I state = MoveToUnload A pp. Ready — ^ state : = Unloading 
I state = Unloading — >■ UnloadPress ; state : = MoveToDeposit 
I state = MoveToDeposit — >■ state : = Depositing 
I state = Depositing — ^ state : = MoveToLoad 
I state = MoveToLoad A pp. Ready — ^ state : = Loading 
od 
]| 



The specifications above embed the same information as illustrated by Fig. 2 
and Fig. 3. However, in order to further develop the system, this information is 
too abstract. We therefore proceed by specifying the methods Ready and Safe, 
the predicates Received and Delivered as well as the abstract actions LoadPress 
and UnloadPress. The basic mechanism for this consists in enlarging the state 
of the components, i.e., in adding new attributes to each class body. Adding 
attributes and making thereby the specifications of the methods, predicates and 
actions more concrete respects the principles of the superposition refinement, 
and hence we correctly develop the control systems components specification. 

The method Safe of the Robot models the fact that the robot arms are no 
more inside the press. It becomes apparent that we need two attributes for the ro- 
bot, armi and arni 2 with values from the type set {ext, retr{, standing for exten- 
ded and retracted respectively. Expressing the actions LoadPress, UnloadPress 
requires some extra attributes since we have to model not only the extension 
and the retracting of the robot arms but also the picking up and the putting 
down of blanks from and to the press. As these two actions are performed with 
different robot arms we specify yet two more attributes, namely mgi and mg 2 
modelling the electromagnets that the arms of the robot are fitted with. These 
attributes have two values {on,ojf\ and the respective methods and actions of 
the robot have the following specification: 

Safe = {armi = retr A arm2 = retr) 

LoadPress = {armi ■ = ext ; mgi : = off-, armi : = retr) 

UnloadPress = {arm2 : = ext ; mg2 -. = on ; arm2 : = retr) 
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For the press, we first need to determine the method Ready. This method de- 
scribes the proper interaction position of the press plate along its vertical axis 
and the fact that the blank has not been yet processed. For specifying this we 
need two attributes, pos and blank. The former attribute denotes the position 
on the vertical axis and has the type set {mid, down, top}. The latter attribute 
stands for the existence of a blank in the press and is a boolean attribute with 
two values {F, T}. The method Ready and the predicates Received, Delivered 
can now be specified: 



Ready = {pos = mid A -iblank) V {pos = down A blank) 

Received = {blank), Delivered = {-iblank) 

The update of the attribute blank has to be done accordingly with the picking 
up or dropping of the blank by the robot arms. Thus, the attribute blank must 
be set to value T after the action LoadPress has taken place and to the value 
F after the action UnloadPress has taken place. As the attribute is local to the 
press component, the robot has to be able to access a method for manipulating 
it, SetBlank. This method is declared in the class body Pr. 

The specification of the example illustrates the component-based manner 
used for constructing it. The attributes state of the components are used to 
express the cyclic computation of the control system components as well as for 
synchronising the components with each other. These attributes also provide an 
intuitive transition from the statechart diagrams specification to the 00-action 
systems specification. 

Besides the translation and specification of the elements in the diagrams, 
there might be some other issues to be specified in the 00-action systems speci- 
fication, too. These are usually due to the internal behaviour of the components, 
used for implementing the public methods. 

For instance, we still have to introduce an explicit update for the attribute 
pos, modelling the internal movement of the press plate along its vertical axis. 
The robot and press components have now the following specification: 



Pr — \[ attr state : = Receiving ; blank : = F ■, pos : = mid 
obj rr : Robot 

meth Ready — {pos = mid A -iblank) V {pos = down A blank); 

SetBlank{val) = {blank : = val) 
do state = Receiving A blank A rr.Safe — >■ state : = Pressing 
I state = Pressing pos : = top ; state : = MoveToDeliver 
I state = MoveToDeliver — >■ pos : = down ; state : = Delivering 
I state = Delivering A -iblank A rr.Safe — >■ state : = MoveToReceive 
I state = MoveToReceive — ^ pos : = mid ; state : = Receiving 
od 
]| 



This component specification concludes the first phase of the development. The 
interactions between components are fully specified and this complete specifica- 
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tion respects the principles of the superposition refinement. That is, the functio- 
nality of the components specification is obviously preserved by the introduction 
of the attributes and of the method SetBlank. 



Ro = 1 [ attr state : = Loading ; armi, arm2 : = retr, retr ; mgi, mg2 : = on, off 
obj pp : Press 

meth Safe = {armi = retr A arni2 = retr) 
do state = Loading — > armi : = 6 xt ; mg\ : = off ; armi ■ = retr 
pp.SetBlank(T) ; state : = MoveToFeed 
I state = MoveToFeed — >■ state : = Feeding 
I state = Feeding — >■ state : = MoveToUnload 
I state = MoveToUnload A pp. Ready — >■ state : = Unloading 
I state = Unloading — >■ arm2 : = ext ; mg2 : = on ■, arm2 : = retr; 

pp.SetBlank(F) ; state : = MoveToDeposit 
I state = MoveToDeposit — ^ state : = Depositing 
I state = Depositing — >■ state : = MoveToLoad 
I state = MoveToLoad A pp. Ready state : = Loading 
od 
]| 



Other operations can be performed at this level of the specification as well. 
We can, for example, establish some invariant properties that the components 
have to respect and then formally check that these properties are respected 
by the autonomous behaviour of the components. In this way the components 
specifications deduced from the statechart diagrams specifications are provably 
correct and according to the requirements of the control system. For instance, 
an invariant for the press component can be that the plate of the press is moved 
only within the interval [down, top]. The formal verification of such a property 
was performed for instance in [2], using essentially the weakest precondition 
predicate transformer semantics of actions. 

Starting from a specification that agrees with the requirements of the control 
system to develop, the individual components can be further refined to model 
the physical plant, the software controller, sensors, and actuators. This forms 
the object of the following section. 

6 Refining Control System Components 

In this section we show how can the superposition refinement principle be used 
together with a parallel composition rule for 00-action systems for refining a 
component specification towards the structure illustrated in Fig. 1. The number 
and type of the specific control system entities are discovered during this phase 
of the component development. 

Separating the Plant and the Controller. A control system component 
consists in a physical plant that is coordinated by a software controller. The 
evolution of the plant can be discrete or continuous, but when it reaches specific 



170 



L. Petre and K. Sere 



states, some control decisions have to be taken. The plant and the controller are 
modelled by a class each. The plant class contains the transitions to the new 
states. Before each such transition, a controller method is called, taking care 
of the required decisions to be taken. If no such decision is necessary, then the 
respective controller method body is modelled with a stuttering action skip. The 
controller class has only methods, thought of as ‘interrupt procedures’ [23]. 

In order to ensure a correct component development, the splitting of the 
existing specification into a two-class specification has to represent a component 
refinement. This operation is achieved using an intermediary step. The existent 
component specification is first refined into a similar class that has the actions 
and methods differently organised. First, a number of methods are added, as 
many as many actions the initial specification has. Second, each action of the 
form state = actl A A ^ B ; state : = aet2 is replaced with state = actl -A 
act2;state: =act2, where the method act2 = (state = aetlAA -A B;state: =aet2). 
Obviously, the effect of the new action is the same as the effect of the old action. 
Only some redundancy has been added. Since adding methods and keeping the 
old functionality agrees with the superposition refinement step, the process so 
far is a refinement. Third, for each attribute that is read in the body of the 
methods we add a method GetAttr = (attr) and replace each reading of the 
attribute with a call to this method. Again, this process represents a refinement 
step. For instance, the intermediate class body between the press specification 
from the previous section and the desired specification containing a plant and a 
controller is like this: 



Pr' = II attr state : = Receiving ; blank '. = F ; pos : = mid 
obj rr : Robot 

meth SetBlank(val) = (blank : = val) ; GetBlank = (blank)-, 

Ready = (pos = mid A -ip. GetBlank) V (pos = down A p. GetBlank)-, 

Pressing = (state = Receiving A p. GetBlank A rr.Safe — >■ state : = Pressing)-, 
MoveToDeliver = (state = Pressing — ^ pos : = top ; state -. = MoveToDeliver); 
Delivering = (state = MoveToDeliver pos : = down ; state -. = Delivering)-, 
MoveToReceive = (state = Delivering A -^p. GetBlank A rr.Safe 
state -. = MoveToReceive)-, 

Receiving = (state = MoveToReceive — ^ pos : = mid ; state : = Receiving) 
do state = Receiving Pressing ; state : = Pressing 

I state = Pressing — >■ MoveToDeliver ; state : = MoveToDeliver 
I state = MoveToDeliver — >■ Delivering ; state : = Delivering 
I state = Delivering — >■ MoveToReceive ; state : = MoveToReceive 
I state = MoveToReceive Receiving ; state : = Receiving 
od 

II 



Having this intermediate class, a specific rule of 00-action systems can be 
applied, namely the parallel decomposition. Given two classes, their parallel com- 
position consists in the union of their attributes, object variables, methods, and 
actions, such that if one of the classes has a reference (object variable) to ano- 
ther, this object variable appears no longer in the composition and the methods 
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of the latter class are called in the former without the respective prefix. Other 
classes not participating to the composition may have references to one of the 
composing classes. Such references are replaced with a reference to composition 
of these classes. This operation is formally described elsewhere [6,3]. 

The reverse operation can be applied on the intermediate class and hence 
split it into two classes: a plant and a controller. The controller class contains 
all the controlling methods introduced previously and also the methods used to 
signal triggering events to other components. All the attributes that are modified 
in the controller methods are also declared in the controller class. The attributes 
that are only read in these methods are declared in the plant class, together 
with their SetAttr and GetAttr methods. Since the state attribute is used both 
in the plant actions and in the controller methods, it is duplicated in each class. 
Its role is to help the proper coordination of the plant with the controller. It is 
important to note, however, that the two ‘states’ are different attributes. The 
press will always contain a reference to the controller for calling its methods. 
The controller will keep a reference to the plant only if it needs some attributes 
that are declared in this class. 

The parallel decomposition of a class into several classes that have the same 
effect as the initial class is only a structuring technique. Semantically, the initial 
and the final specification represent the same component. Hence, the overall 
process of splitting of a component specification into a plant and a controller 
is a correct refinement step, since the intermediate step was a superposition 
refinement. Therefore, the process of control system component development 
remains correct. 

For instance, the press component is now specified as follows: Press = {< 
prp, PrP >, < prc, PrC >}. Since the attribute blank is read by the controller, 
there is also a reference p : prp from the controller to the plant and a method 
GetBlank declared in the press plant. 



PrP = II attr state : = Receiving ; blank : = F 
obj p : pro 

meth SetBlank(val) = {blank : = val) ; GetBlank = (blank) 
do state = Receiving — ^ p. Pressing ; state : = Pressing 

I state = Pressing p.MoveToDeliver ; state : = MoveToDeliver 
I state = MoveToDeliver — >■ p. Delivering ; state : = Delivering 
I state = Delivering p.MoveTo Receive ; state : = MoveToReceive 
I state = MoveToReceive — >■ p. Receiving ; state : = Receiving 
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PrC = |[ attr state : = Receiving ; pos : = mid 
obj rr : Robot ; p : prp 

meth Ready — {pos = mid A -ip.GetBlank) V {pos = down A p.GetBlank)\ 

Pressing = {state = Receiving A p.GetBlank A rr.Safe state : = Pressing); 

MoveToDeliver = {state = Pressing — > pos : = top ; state : = MoveToDeliver); 

Delivering = {state = MoveToDeliver pos : = down ; state : = Delivering); 

MoveToReceive = {state = Delivering A -^p.GetBlank A rr.Safe — >■ 
state : = MoveToReceive); 

Receiving — {state = MoveToReceive pos : = mid ; state : = Receiving) 

II 

The robot component can be refined using the same pattern into a a robot 
plant and a robot controller. The attributes of the robot are only modified, so 
they are declared all in the controller. In the following we skip the specification 
of the robot component for brevity. 

Specifying Sensors and Actuators. The development of a control system 
is initiated by splitting the overall system into several components. This step 
is usually not difficult, as a group of related services to be performed by the 
system are likely to be implemented by the same component. A control system 
normally contains also some typical entities like sensors and actuators. However, 
it is not obvious from the beginning how many of these entities are necessary 
and likewise their types are not easy to determine. It is more natural instead 
to discover the sensors and the actuators on the way, as they are needed. We 
adopt this approach here and determine the sensors and the actuators in the last 
refinement step, from the attributes of the components and their distribution in 
the plant or in the controller. 

The separation into a plant and a controller implied also a splitting of the 
attributes in the two entities. However, the attributes of the plant and of the 
controller model usually more than just properties of these entities, as their va- 
lues are read by the other entities. They would thus model sensors and actuators, 
used within one component for synchronising the physical plant with the soft- 
ware controller and also used indirectly for modelling the interaction between 
components, via the boolean methods modelling triggering events. 

To conform with a control system specification as depicted in Fig. 1 we have to 
establish which attributes are sensors and which are actuators. The strategy for 
this is to check what is the information read by the controller and to transform 
it into sensors, then to check what is the information read by the plant and 
transform it into actuators and finally to make all updates of the sensors within 
the plant and all updates of the actuators within the controller as shown in the 
specification below. 

For instance the blank attribute is read in the press controller (via the method 
GetBlank), so it should model a sensor that is supposed to sense whether there 
is something in the press of the consistence of a blank. When a blank is put 
into the press or taken from the press, the sensor should reflect these changes. 
The other press attribute pos models an actuator, defined and updated by the 
controller. 
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By applying the same splitting strategy as for separating the plant and the 
controller we get a final specification of a control system component according to 
Fig. 1. This specification is the result of a correct development process based on 
refinement techniques. A component will consist in a collection of sensors, actua- 
tors, plant and controller classes. For instance, the press component has become: 
Press = {< prp,PrP >,< prc,PrC >,< Blank, Blank >,< ALevel, ALevel > 
, < SLevel, SLevel >}. 



Blank = |[ attr val : = F 

meth SetBlank(v) = {val : = v) ; GetBlank = {val) 

II 

SLevel = |[ attr val : = mid 

meth Set{v) = {val : = v) ; Get = {vat) 

II 

ALevel = |[ attr val : = mid 

meth Set{v) = {val : = v) ; Get = {val) 

II 

PrP = |[ attr state : = Receiving 

obj p : pro ; slev : SLevel ; alev : ALevel 
do state = Receiving — >■ p. Pressing ; state : = Pressing 

I state = Pressing — >■ p.MoveToDeliver ; {alev. Get = top — >■ slev. Set {top) \ 
state : = MoveToDeliver 

I state = MoveToDeliver — >■ p. Delivering ; {alev. Get = down — >■ slev. Set {down) \ 
state : = Delivering 

I state = Delivering — >■ p.MoveToReceive ; state : = MoveToReceive 
I state = MoveToReceive — >■ p. Receiving ; {alev. Get — mid slev. Set {mid)-, 
state : = Receiving 

od 

II 

PrC = |[ attr state : = Receiving 

obj rr : Robot ; bl : Blank ; spos : SLevel ; apos : ALevel 
meth Ready = {spos . Get = mid A->bl. GetBlank) V {spos. Get = down A bl. GetBlank); 
Pressing = {state = Receiving A bl. GetBlank A rr.Safe state : = Pressing); 
MoveToDeliver = {state = Pressing — > apos.Set{top) ; state : = MoveToDeliver) ; 
Delivering = {state = MoveToDeliver — ^ apos .Set{down) ; state : = Delivering); 
MoveToReceive = {state = Delivering A -^bl. GetBlank A rr.Safe — >■ 
state : = MoveToReceive); 

Receiving = {state = MoveToReceive — >■ apos.Set{mid) ; state : = Receiving) 

II 



One can notice the suitability of 00-action systems in modelling component 
interfaces. Thus, the robot component maintains a reference pp to the press 
component and uses among other methods the method SetBlank declared in 
the press component. Within the press component, this method is declared first 
in the class body Pr, then in Pr' , then in PrP and finally in the class body 
Blank. From the robot component’s perspective, this is however irrelevant. The 
interaction works as long as the name of the method remains unchanged. 
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Concluding the control systems development, we have determined the sen- 
sors, the actuators, the cyclic evolution of the physical plant and the control 
software following completely software engineering techniques. The controller 
methods get activated when corresponding sensor values change, as a result of 
some actuators actions. Moreover, the state attributes become obsolete and can 
be more or less replaced by up-to-date information received via the sensors. 

7 Conclusions 

In this paper we have proposed a development method for control system com- 
ponents. As a novelty, our method combines UML statechart diagrams and 00- 
action systems, based on their compatibility. The method shows the power of 
software engineering techniques in developing systems where it is not clear from 
the beginning which parts will be implemented in hardware and which in soft- 
ware. 

A particular role is played by the refinement techniques that help identifying 
different hardware or software entities. It seems that the principles of refinement 
and its different approaches as data, algorithmic, or superposition refinement go 
beyond the context of formal methods for software construction where they were 
introduced. 

Using the two specification techniques for the development of components, 
a number of integration questions appear. The most important result here is 
that event-based statechart diagrams and state-based 00-action systems can 
integrate rather naturally, as they both model active objects. Consequently, we 
can take advantage of this integration result and work towards the development 
of a formal semantics for UML statechart diagrams in terms of 00-action sy- 
stems. In this context it seems interesting to define the notion of refinement for 
statechart diagrams. However, this is left for future research. 
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Abstract. One of the results of research into formal system specifica- 
tion has been the large number of notations which have been developed. 
Of these notations, automata have emerged as a promising vehicle for the 
specification, and particularly the analysis, of systems. This is especially 
so when the systems under consideration include timing requirements, 
and timed automata model such systems as a finite set of states with 
timed transitions between them. However, not all specifications involve 
deterministic timing, and stochastic automata can be used in these cir- 
cumstances. 

In this paper we consider both timed and stochastic automata, and de- 
monstrate how they can be used in the same design. We will also consider 
what analysis of the specification can then be performed. In particular, 
we will describe how to translate stochastic to timed automata, and look 
at two approaches to model checking the stochastic components of an 
integrated design. 

Keywords: Timed automata, stochastic automata, model checking. 



1 Introduction 

One of the results of research into formal system specification has been the large 
number of notations which have been developed. There are now many notations 
which can be used to specify and design systems. Potential problems with this 
are that specifiers working on the same system may be familiar with different 
notations, and that different notations may be better suited for different parts 
of the same design. 

Even within notations there can be variants, and in this paper we will confine 
ourselves to automata. We will demonstrate how different automata notations 
can be used in the same design, and how analysis of the specification can be 
performed according to the particular notation used. This means that designers 
need not be restricted to a monolithic notation, and that the most convenient 
notation can be chosen to describe each component within the design. 

In this paper we will focus on timed automata with deadlines and stochastic 
automata. Timed automata are now well established as a specification nota- 
tion, and there has been extensive work on analysis techniques for them, and in 
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particular model checking algorithms. Stochastic automata are a relatively new 
extension to timed automata, where the emphasis has been shifted from deter- 
ministic timing to timings picked from a probabilistic distribution, thus enabling 
a new range of systems to be specified. 

The structure of the paper is as follows. In Section 2 we present the automata- 
based notations that we will use throughout the paper, and in particular timed 
automata with deadlines and stochastic automata. Section 3 presents an example 
using these notations which models cars arriving at a port wishing to board 
a ferry. Section 4 looks at possible ways to analyse such a specification, and 
compares them with each other. 

Specifically we are interested in timed vs stochastic analysis. For the former 
there is a wide range of techniques available and therefore we concentrate on how 
we can integrate the stochastic components into this analysis. To this end we 
show how a stochastic automata can be translated into a timed automata with 
deadlines, as this allows the integrated specification to be interpreted within a 
single simpler notation. 

However this clearly involves a loss of some stochastic information, and to 
perform stochastic analysis we look at two approaches to model checking the 
stochastic components of an integrated design. Finally in Section 5 we draw 
some conclusions, and mention ongoing and possible future work. 



2 Notations 

For the purposes of this paper, we choose automata as a “base” notation, and 
we will use the timed automata with deadlines (TAD) of [5], and the stochastic 
automata (SA) of [10] as necessary. Although different versions of timed auto- 
mata exist, we chosen TAD over the others because of the ease of translating 
from SA to TAD (see Section 4.1.) Both TAD and SA are extensions of ordinary 
automata, and we give definitions for them now. 

Definition 1 In this paper, a TAD is: 

— A discrete labelled transition system (W,— >■, A) where 

• W is a finite set of discrete states 

• A is a finite set of actions 

• — ^Cf/fxAxWisan untimed transition relation 

— A set A = {xi, . . . , a:„} of non-negative real valued variables called clocks. 

— A labelling function h mapping untimed transitions into timed transitions: 
h{u, a, u') = {u, (a, g, d, r), u') where 

• g and d are the guard and deadline of the transition. Guards and dead- 
lines are predicates p defined by the following grammar: 

p ::= \ pAp\p\/p 

where x £ X , w £ R^q and # G {<, <, >, >}. 

— r is the set of clocks which are reset to zero when the transition takes place. 
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A transition may occur only when the guard is true, and must occur if the 
deadline is true. (The definition of the grammar for defining the guard and 
deadline predicate is slightly modified from the one found in [5].) 

The clocks in TAD always begin counting at zero and count upwards. This 
is in contrast to the clocks in SA, which are set to some value in according 
to their probability distribution function, and count downwards. 

As an example, consider the TAD depicted in Figure 1. From state mq, the 
action a may occur provided the clock x\ is greater than 2, and must occur if it 
is equal to 4. When it does occur, the clock X 2 is reset and the automaton moves 
to state u\. From here, the action h may occur provided clock x\ is in the range 
[6, 8] and clock X 2 is greater than 3. The deadline imposes no restriction, and 
when the action does occur no clocks are reset. 




Fig. 1. A Timed Automaton with Deadlines 



Stochastic automata are an extension of timed automata, in which the time 
at which actions occur may be a random variable. In this paper we use the 
stochastic automata defined in [10], which are presented below. 

Definition 2 A stochastic automaton is a structure (5, sqi C, A, — k, F) where: 
5 is a set of locations with sq € S being the initial location, C is the set of all 
clocks, and A is a set of actions. 

— ►C 5 X (A X C) X 5 is the set of edges. If s and s' are states, a is an 
action and C is a finite subset of C, then we denote the edge (s, a, C, s') G — ► 

a.,C a 

by s — ► s' and we say that C is the trigger set of action a. We use s — ► s' as a 

a,C 

shorthand notation for 3 C .s — ► s' . In this paper we will associate only a single 
clock with each action. 

K : iS — > ¥fin{C) is the clock setting function, and indicates which clocks are 
to be set in which states, where Ffin{C) is the finite powerset of clocks. 

F : C — >■ (M — [0, 1]) assigns to each clock a distribution function such that, 
for any clock x, F{x){t) = 0 for t < 0; we write Fj, for F{x) and thus F,^{t) 
states the probability that the value selected for the clock x is less than or equal 
to t. Each clock a; G C is a random variable with distribution F^. 
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In this paper we will assume that clocks are only used on transitions emana- 
ting from the states in which they are set. We will also find it easier to refer to 
probability density functions (pdf’s), which are the derivatives of the distribution 
functions. We will use for the pdf of F^. 

As an example, of a stochastic automaton, consider Figure 2. This is written 
({so, si}, So, {x, y},{a, b}, K, (Pj;, Py}) where 

-►= |(so, a, {a:}, si), (sq, b, |y}, sq)}, and the pdf’s for clocks x and y are 

P^(t)= 4- 2t,if t e [1,2] Py{t)= 2t - 2, if t e [1,2] 

= 0, otherwise =0, otherwise 

as depicted. The horizontal axis measures time, and the vertical axis measures 
the probability of the clock being set to a value less than that time. 

The SA starts in location sq, and both clocks x and y are set according to 
the functions and Fy. If clock x expires first, then action a is triggered and 
the automaton moves to location si. This location has no outgoing transitions, 
and so nothing further happens. If clock y expires first, then action b is triggered 
and the automaton returns to state sq- The clocks are reset according to their 
distributions, and the process is repeated. 






Fig. 2. A Stochastic Automaton 



In the following Section we will show how we can combine both stochastic 
and timed automata using a larger example. 

3 Example - A Car Ferry 

To illustrate these ideas, we will specify a system consisting of a number of cars 
at a port, trying to get on to a ferry (see Figure 3.) The cars enter the port 
at the traffic lights, and join the queue in the middle of the port. When they 
reach the front of the queue they move to the next free kiosk, where they are 
processed, and then they go on to join the ferry. 

In this example, there are two parts of the model over which we do not have 
direct control. One is the arrival of the cars into the queue, and the other is the 
rate at which individual kiosk workers work. For both of these we use stochastic 
automata to model the inherent uncertainty. 
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queue 



traffic lights 



T 



Fig. 3. The port 



We will consider that actions synchronise with other actions of the same 
name, and that in a parallel composition the intersection of the alphabets syn- 
chronise (as in [11].) For the car arrivals, we use the distribution shown in Fi- 
gure 4. This can be thought of as modelling the behaviour resulting from a set 
of nearby traffic lights: If one car arrives it is quite likely that another will arrive 
very shortly afterwards, (between 5 and 10 seconds). If no car arrives in this time 
then the lights will turn red, and no car will be able to arrive until 30 seconds 
have passed. Whether or not this function is an accurate representation of the 
environment in which the system will have to operate can only be determined 
by observing the actual behaviour of the cars. 





seconds 



Fig. 4. Modelling car arrivals as an SA 



We have a little more control over the behaviour of the kiosks, in that we 
can choose how many are open at a time. However, we cannot determine the 
rate at which the individual operators work, and so this must be represented as 
a stochastic function. 

An individual kiosk is modelled as an SA, as shown in Figure 5. We model 
the kiosk as opening immediately, and twelve seconds after a kiosk opens, a car 
leaves the queue to be processed. This is modelled by the clock C 2 , which is 
deterministically set to 12 seconds every time state K 2 is entered. 
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Fig. 5. Modelling a single kiosk as an SA 

The processing takes between 30 and 60 seconds, and this continues until the 
kiosk is closed. This is modelled by the clock C3, set to a value between 30 and 
60 seconds according to the pdf: 

P-(^)= if [30,60] 

= 0, otherwise 

Here we are in fact modelling the impact on the queue (using the car— leaves 
actions) rather than on the kiosk directly. 

We include the state KA in order to be able to distinguish the state in which 
the first car has been processed (and the second one has left the queue.) We will 
make use of this later in the analysis of the kiosk. 

The queue that the cars form is essentially passive. It does not instigate 
either the car -arrives or the car— leaves actions, and it therefore needs no time 
deadlines (as TAD) or clocks (as SA) and can be modelled as a simple automaton. 
This is shown in Figure 6 (where states 3 and 4 and the transitions between them 
have been elided). 

Notice that quite general distributions are allowed in our stochastic auto- 
mata. Here we have used combinations of uniform and triangular distributions, 
and in general arbitrary distributions are allowed. 



car arrives 



car arrives 




car arrives 




Fig. 6. Modelling the queue as an automaton 
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4 Analysing the Integrated Specifications 

In order to analyse a specification defined using a number of different notations, 
we have two possibilities. We can either re-interpret all the components wit- 
hin one notation (and then use whatever analysis that notation permits) or we 
can analysis the components of the specification. Here we briefly consider both 
approaches which are illustrated using the car ferry example. 



4.1 Translating SA to TAD 

In this Section we consider the first approach and show how to interpret sto- 
chastic automata in terms of timed automata with deadlines. The interpretation 
must preserve the behaviour of the SA within a TAD as far as possible, so for 
each SA we must be able to generate the TAD which is capable of exactly the 
same set of runs^ as the SA. However, since a TAD cannot represent probabilistic 
information, this translation will necessarily lose all probabilistic information. 

To illustrate the ideas we begin by deriving timed automata with deadlines 
from the stochastic automata in the example, and then give the formal definition 
of the translation. 

Consider the SA (Figure 4) that models the arrivals of cars at the car ferry. 
The clock ci is set (as we may deduce from the pdf of clock ci) to some value in 
[5, 10] U [30, 35] U [55, 60] U [80, 85], and then proceeds to count down. The action 
car_arrives occurs when this clock expires. 

We derive an corresponding TAD (Figure 7) which must therefore be capable 
of performing the action car^arrives at any time in the range [5, 10] U [30, 35] U 
[55,60] U [80,85], and the action must be performed by (or at) time 85. We use 
x\ to correspond to clock ci, and set the guard (the permitted occurrence times) 
to Xi € [5, 10] U [30,35] U [55,60] U [80, oo) and the deadline to Xi ^ 85. Setting 
the deadline to greater than or equal to 85 means that if this state is entered 
when x\ ^ 85 the action must occur. 

In the SA, clock c\ is reset every time the state A\ is entered, so in the TAD 
r (which is the set of clocks being reset to zero when the transition occurs) is 
set to {xi}. 




car arrives 

ff:a:ie[5,10]U[30,35]U[55,60]U[80,85] 

(i:a:i=85 

r:xi 



Fig. 7. The translation of the car arrivals into a TAD 



^ A run is a (finite or infinite) sequence of timed actions. 
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This turns out to be an automaton with just one state, however, not all 
translations are this simple, for example the kiosk description (Figure 5) becomes 
the TAD in Figure 8. 




d:true S-true 

r:0 d'.true 

r:0 



car leaves 

g-.x^'^ZO 

d:x3^60 

r:x3 



Fig. 8. The translation of a single kiosk into a TAD 



Using the ideas illustrated in these examples we can formalise the full defini- 
tion of the translation of stochastic automata to timed automata with deadlines 
as follows. 

Definition 3 Translating an SA into a TAD. 

Let (5, sq,C, a, — K, F) be a stochastic automaton. This automaton is map- 
ped to the timed automaton (Z, — A) where 



- Z = S 

- A = A 



— — >T is the transition relation — ► with the clocks removed, i.e. 

— Z X Ax Z where 

— >T= {{z, a, z') I 3 Ca-{s, a, Ca, s') e -►A s = z A s' = z'} 

— The set X contains (non-negative real-valued) clock variables, labelled Xi 
and indexed as the SA variables. 

V i.Xi € X ^ Ci G C 

— h{s,a,s') = {s, {a, g, d,r), s') where Ca is the trigger set for action a and 

• 9 = (AciGCa ^ min(cj) 

A 

Vci£C„ S ran(cj)) 

V 

f\cidCa ^ max(c,) 

• d = AcieC„ ^ max(cj) 

where min(ci), max(ci) and ran(ci) are the minimum, maximum and 
range respectively of the pdf of clock c^. 

• r = k(s') 



We are endebted to Pedro D’Argenio [9] for this definition, and it is discussed 
in more detail in [7]. 
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With the stochastic components turned into timed automata with deadlines, 
temporal observations of the system can be made, for example to address que- 
stions such as “Is a particular throughput of cars possible?” , or “With only one 
kiosk open, what is the minimum/ maximum time before the queue overflows?” . 
To support this task, work has started on extending the LUSCETA tool [12]. It 
currently supports the creation and editing of timed automata and timed auto- 
mata with deadlines. It also supports the compositon of either type of automata 
providing all automata are of the same type (the composition rules for timed 
automata with deadlines are presented in [4]). However, the simulator currently 
only supports timed automata; work is still required to extend this to timed 
automata with deadlines. 

This translation provides us with the ability to analyse the temporal pro- 
perties of a specification that originally included stochastic information. Ho- 
wever, this translation has the obvious drawback that the exact stochastic pro- 
perties of the specification can no longer be investigated. We move on to consider 
this in the next Section. 

4.2 Model Checking Stochastic Automata 

The alternative to translating SA to TAD (and thereby forfeiting the stochastic 
information) is to keep the stochastic information by retaining the SA, and per- 
forming more complex analysis only on the stochastic components. Much of the 
work done in stochastic modelling and performance evaluation uses the assump- 
tion that the random times at which actions occur are drawn from exponential 
distributions. While this allows many performance evaluation results to be de- 
rived, in practice it is unrealistic to consider only exponential distributions, and 
it is necessary for arbitrary distributions to be considered. 

The analysis technique we consider is model checking [8]. This has proved 
very successful in many applications, and applying it to stochastic systems opens 
up several new research issues. 

In this Section we discuss two approaches to model checking stochastic au- 
tomata. The first calculates exact answers for stochastic automata involving ar- 
bitrary distributions. However, the cost of this precision is the complexity of the 
algorithm and we also describe a further algorithm which uses a discretisation 
to reduce this complexity and is discussed in more detail in [6]. 

A Probabilistic Real Time Temporal Logic. The basic approach we take 
to model checking is to try to show that a temporal logic property is satisfied by 
a stochastic automaton description of the system. Here we use a simple probabi- 
listic real-time temporal logic. The purpose of the logic is to express properties 
that we wish to check the stochastic automaton against and the logic we define 
allows us to check a range of such properties. 

The syntax of our logic is 

::= tt I ap I ^ I ■01 A ■!/'2 I [4>i U^c /> 2 ] ^ P 
^ tt I ap I -. (/ I </i A </i 2 
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Here ap is an atomic proposition, c € N (natural numbers), p € [0,1] is a 
probability value and {<,>,^,^}. The temporal aspects are described 

by [^1 lA^c 4’2] — P which is an “until” formula. In general we would associate sets 
of atomic propositions with states of automata; however here it will be sufficient 
to assume a single distinct proposition for each state, (effectively identifying 
states and propositions) so that each state models the set of propositions 
{A 2 ,,tt}. Using this logic we can also define a number of derived operators, for 
details see [6]. 

To understand an “until” formula, it is simplest to begin with an untimed, 
non-probabilistic version. Intuitively, (pi hi <p2 reads as: (pi holds until p2 does. 
The subscript is the time restriction — eg. if ^ is < then p 2 must hold before 
(or at) time point c. The addition c^p is a probability restriction — e.g. if ~ is 
> then pi hi r.,cp2 must be true with probability greater than p. 

The until formulae can only be used at the top level — they cannot be nested. 
This is because the model checking algorithms we discuss can only evaluate 
until formulae from the initial state; this is a necessary restriction of our current 
approach. 

With this syntax, an example of a valid formula that we can check against 
the stochastic automaton in Figure 5 would be ^tU<QnK 4 \ > 0.3. This states 
that the probability of reaching the state K/i (and therefore having processed 
the first car) within 60 seconds is greater than 0.3. 

It should be clear that since we do not allow the until formulae to be nested 
we can use the following recipe in order to model check a formula ip of our logic 
against a stochastic automaton A. 

1. For each until subformula (i.e. of the form [piU ^cp 2 ] — p) in ^p perform an 
individual model check to ascertain whether 

A \= [plU.^cp2] ^ P 

2. Replace each until formula in ip by tt if its corresponding model check was 
successful, or ff (-■ tt) otherwise. 

3. Replace each atomic proposition in ip by tt or ff depending upon its value in 
the initial location of A. 

4. Ip is now a ground term, i.e. truth values combined by a propositional connec- 
tive (-1 and a). Thus, it can simply be evaluated to yield a truth value. The 
automaton is a model of ip if this evaluation yields tt, and is not otherwise. 

We assume that when we wish to model check a property against an automa- 
ton, we are also given an adversary [3] to resolve the nondeterminism within the 
automaton. Without this adversary, enumerative analysis would not be possible; 
the provision of an adversary is a prerequisite of model checking. To understand 
the notion of an adversary here, we must explain in a little more detail our 
conceptual model of automata. We consider an automaton to operate within an 
environment, and for this environment (if unspecified) to be the most general 
environment possible, and to permit all behaviours of the automaton^. We can 

^ This follows closely the CSP [11] notion of process and environment, where the 
environment, if unspecified, is taken to be the most nondeterministic process. 
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then think of an adversary as an environment which is deterministic with respect 
to the automaton, and therefore resolves all nondeterminism within it. 

If, for example, we were checking a property of a single kiosk, we could choose 
the adversary to perform the open action immediately, and to close the kiosk 
again after three hours. 

This recipe employs standard techniques apart from the individual checking 
that A ^ c4>2] — P and this is what our two algorithms address. 

The First Algorithm — Using Region Trees. The first algorithm (called the 
region tree algorithm) has similarities to the region graph construction of [2] , [1] , 
[13]. In general for this algorithm, we must assume that the clock distribution 
functions are continuous within the range^ of the function, in order to ensure 
that the probability of two clocks expiring at the same time is zero. 

The algorithm works by unfolding the automaton to construct a region tree, 
and at each stage in the unfolding using the temporal logic formula to construct 
a probabilistic region tree. The regions are formed using the notion of valuation 
equivalence. A valuation records the values of all the clocks in a particular state 
at a particular moment in time. The unique clock a G C, which we add to the 
set of clocks, is used to facilitate the model checking. It keeps track of the total 
time elapsed in the execution of the stochastic automaton, but plays no part in 
the behaviour of the automaton. 

Definition 4 A valuation is a function v : C]J{a} — >■ M1J{T} such that v{x) = 
T or v{x) < Xmax, where Xmax is the maximum value to which clock x can be 

set. If d € R>o, V — d is defined by Va; G ClJ{a}-(w — d){x) v{x) — d. The 
function min(ii) returns the value of the smallest defined clock. 

Since we assume that clocks are only used in the states in which they are set, 
there is no need to remember their value once the state has been exited. Only 
the clock a maintains its value; the rest are set to T. At the initialisation of a 
stochastic automaton, clock a is set to the time value of the temporal formula, 
and all other clocks are undefined. We define this initial valuation as 0„, if 
0(a) = n. 

We also need a notion of equivalence between the valuations, which we will 
use to construct a finite number of regions at each node within the probabilistic 
region tree. 

Definition 5 Two clock valuations v and v' are equivalent (denoted v = v') 
provided the following conditions hold: 

— For each clock x G C]J{a}, either both v{x) and v'{x) are defined, or 

v{x) =_L and v'{x) =T. 

— For every (defined) pair of clocks x,y G C lj{a}.?;(a;) < v{y) v'{x) < 

v'{y)- 



^ The range of a function is given by the set {t \ F^{t) > 0}. 
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The same clocks are defined in each valuation, and the order of the values 
of the defined clocks is all that is important, since the actions are triggered by 
the first clock to expire. Therefore we only need to know whether one clock is 
greater than or less than another. 

In building the region tree, each level of unfolding comprises two steps. First, 
the regions within the region tree are formed by distinguishing the equivalence 
classes at each node, then the nodes which can be reached given these equivalence 
classes are calculated using the SA. 

The probabilistic region tree records the resolution of the nondeterministic 
choices and the probabilities at the final nodes represent the chances of taking 
the particular sequence of actions that end in that node. 

At each iteration, we update the information we have on the probability of 
a path satisfying the formula. To do this, we define three new propositions, and 
each node of the probabilistic region tree is labelled with p, f or u: p, if it has 
passed (it is the end of a path which models the bounded until formula ip); f, if it 
has failed (it is the end of a path which cannot model ip), or u, if it is undecided. 
We also have two global variables, Ap and Af, which keep running totals of the 
probabilities of the pass and fail paths. 

The basic idea of the model checking algorithm is that we check the values of 
Ap and Af at each stage, and if we cannot deduce from these the truth or falsity 
of the formula we are checking, we look more closely at the undecided nodes. 
That is, we extend the undecided paths by each possible subsequent action, label 
these new nodes p, f or u, and calculate their probabilities. We then add these 
probabilities to Ap and Af and repeat. 

To determine the probabilities on the arcs, we need to use probability density 
functions of the distribution functions, and integrate these in the order given by 
the valuation equivalence class. It is this integration that is the cause of the 
complexity in this region tree algorithm. 

As an example, consider the formula mentioned earlier: [tt U <60^4] > 0.3, 
which states that the probability of the first car processed by the kiosk being 
processed within one minute from the kiosk opening is greater than 0.3. Even 
though the kiosk contains a deterministically set clock (c2 is set to 12), we can 
analyse it using the region tree algorithm because no other clocks can expire at 
the same time. 

An example of a nondeterministic region tree is shown in Figure 10. Consider 
first the SA in Figure 9. When the clock x fires, both transitions a and b are 
enabled, because both are governed by x. This gives rise to the nondeterministic 
region tree in Figure 10, and if we are to model check such a region tree, the 
nondetministic choice between a and b must be resolved by an adversary. 

The region tree for this example is shown in Figure 11. Because there are no 
nondeterministic choices in this region tree, the probabilistic region tree will be 
structurally identical, the only difference being the labelling. For this reason, we 
do not present the probabilistic region tree. 

Consider region Ki first. Since we are interested in the behaviour of the 
kiosk after it opens, we have an adversary which makes the action open happen 
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Fig. 9. A nondeterministic Stochastic Automaton 




Fig. 10. A nondeterministic region tree 



immediately. Thus the automaton moves to state K 2 , where the clock C2 is 
set. Since clock C2 is deterministically set to 12, we only consider the valuation 
equivalence c\ < a^, and the region graph moves from region 0 to region 1. The 
superscript indicates that this is the first time the clock has been set. 

The automaton moves to state A3 when clock C2 expires, this is represented 
by the transition from region 1 to region 2. The clock a has not expired by this 
state, since it is greater than clock C2, which has only just expired, but we have 
not yet reached state K4, so in the probabilistic region tree we would label this 
state u (undecided). In this state clock C3 is set, and there are two valuation 
equivalences (where ai is the value of clock a at the time of transition): C3 < 
(represented by region 3) and < C3 (represented by region 4). Both of these 
moves will move the automaton to state K 4 when clock C3 expires, but in one 
instance (region 4 to region 6) it is too late, because clock a has already expired, 
and so more than 60 seconds have passed. Region 6 is therefore labelled f in the 
probabilistic region tree. In the other instance (region 3 to region 5) state K 4 
has been reached within 60 seconds, and it is therefore labelled p. 

To determine the exact probability of reaching region 5 (and any other regions 
labelled with p), we need to use the probability density functions associated with 
the clocks. In our example, since we know that the transition from state K2 to 
state A3 occurs at precisely 12 seconds, ai is 48, the problem reduces to solving 
the integration 

Pc3 dt 
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which, since Pc3(0 = 0 when t is less than 30, is equal to 



1 

4 ^ 



/■48 



{t — 30) dt 



130 



which evaluates to 0.36, and so the formula is true. 

This method could easily be adapted to answer queries such as “What is the 
probability of reaching a certain state within a certain time?” and could return 
a precise answer. 

When the time of occurrence of one event may be dependent on the time 
of occurrence of a large number of other events, all the probabilistic density 
functions must be considered in order to calculate the probability of occurrence 
of one event, and the integrals which result become very complex. In order to 
avoid this, we consider a second algorithm, which uses discretisation. 




Fig. 11. Diagram for region tree algorithm 



The Second Algorithm Approximations Using Discretisation. This 
algorithm avoids the calculation of integrals that the region tree algorithm was 
forced to undertake. In order for the discretisation to be possible we need to 
make a number of assumptions. In particular, we assume that the range of the 
clock functions is made up of a finite number of left/right closed intervals; that 
is, we consider only functions F such that 

{t I F'{t) > 0} = 

where [gj,hj] is a left /right closed interval and n is the number of intervals 
in the derivative. For example, the distributions on the stochastic automata 
given in Figures 2 and 3 conform to this template. The template also allows 
deterministic timing since the upper and lower bounds of an interval may be of 
the formula [/>o^<c 4>i] being satisfied at this point. To build the next snapshot, 
the algorithm picks out at each time point nd the transitions that the automaton 
is capable of during the next interval of length S. Because 5 is less than the 
minimum of all the clock lower bounds, a maximum of one transition per path 
can occur in each interval. Recording all possible states of the automaton at each 
time point is therefore enough to record all the possible transitions. 

We also require that 3n.n5 = c, which ensures that one of the snapshots will be at 

exactly time c. 
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A snapshot is built by deriving a matrix for each state s and time t (which 
is a rational number and calculated as nS), denoted matrixes, t), and placing 
in this matrix a record of the probabilities of the various combinations of clock 
values in state s at time t. Each matrix will have as many dimensions as its state 
has clocks. 

Each entry in the matrix matrixes, t) is the probability that at time point 
t, the automaton is in state s, and each clock is within a particular time range. 
Thus, the value matrix{s, t)[ki . . . fc„] is the probability that at time point t, the 
automaton is in state s, and v{ci) € {S{ki — for each clock c^. 

The algorithm stops when either enough information has been gathered to 
determine the truth or falsity of the formula, or enough time has passed so 
that nS > c, and allowing time to pass further will make no difference to the 
information we already have. In this case the result undecided is returned. 



(A2,0) (As, 45) 



0 1 


0 i I 1 0 0 


10 20 C2 




10 20 30 40 50 60 C 3 


(A2,5) 


(A 3 , 55) 


1 0 




i I 1 0 0 0 


10 20 C2 


10 20 30 40 50 60 C 3 



(As, 25) (As, 65) 



0 0 0 --- 

^ ^ ^ q q q 


1 1 0 0 0 0 


10 20 30 40 50 60 C 3 


10 20 30 40 50 60 C 3 



(As, 35) (A4,65) 



0 0 i 1 a 0 


0 0 0 — — — 

^ ^ ^ 81 81 81 


10 20 30 40 50 60 C 3 


10 20 30 40 50 60 C 3 



Fig. 12. matrices for the second algorithm 



Consider again the formula [tt U <eoA 4 ] > 0.3. We choose 5 to be 10. The 
first matrix to be constructed would be m(Ai,0), but the state Ai has no as- 
sociated clocks, therefore the automaton moves immediately to state A 2 , and 
matrix{K2,0) is constructed (see Figure 12). 

This matrix tells us that the probability of clock C 2 being somewhere between 
the values 10 and 20 at time zero is 1. 

There are two different procedures for updating a matrix (that is, to derive 
matrixes, S{n + 1)) from the matrices referring to time S{n)), both of which 
correspond to different situations. The first corresponds to the situation within 
the stochastic automaton where time passes, but the state remains unchanged. 
In this case we must shift the clock configuration probabilities in the previous 
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matrix down by one index step (which corresponds to S time passing) and add 
the result to the matrix we are updating. 

This is the situation here, and matrix{K 2 , 10) is formed as in Figure 12. 

The second procedure is applied when new states can be reached from the 
current state during the S time passing, and involves determining the probability 
of entering these states. We do this by looking at all the probability values in 
the matrix where at least one of the indices has the lowest possible value (10, in 
this example) . If this is the case then we know that at least one clock will expire 
during the ensuing 6 timestep. 

If only one index in the configuration has the value 10 then only one clock 
can expire, and only one state can be entered from this clock configuration, and 
so the matrix for that state is built. 

This is the case from matrix{K 2 , d), and so we get matrix 25), which 
tells us that the probability of being within state at time 25 with clock C3 

between values 30 and 40 is being within state at time 25 with clock C3 

between values 40 and 50 is f and being within state K 3 at time 25 with clock 
C3 between values 50 and 60 is |. 

If more than one index has the value 10, then we simply do not explore that 
configuration any further, and the configuration probability is added to error. 
In the example we are considering, this possibility does not occur. 

In our example, the matrices matrix {K 3 , 55), matrix {K^, 45), matrix{K 3 , 55 ) 
and matrix{K3,65) can all be constructed simply by moving the clock configu- 
ration probabilities with the previous matrices. 

The second way to update a matrix corresponds to a transition from one 
state to another within the automaton. For each matrix entry we calculate the 
clock configuration probability, multiply it by the probability of moving into this 
state at this time, and add it to the matrix entry we are updating. Thus, in the 
example, we get matrix {K 4 , 65), 

We have now reached the timepoint 65, which corresponds to 60 seconds, and 
so the sum of all the probability values in the matrix at this point (^ + ^ + ^ = 
|) is a lower bound on the probability that state K 4 will have been reached by 
time 60. Thus, since we are interested in whether the probability is greater than 
0.3, we can conclude that the formula is true. A smaller 5 would produce a more 
accurate result, but we do not illustrate that here. 

5 Conclusions 

In this paper we have begun to tackle the problem of integrating various auto- 
maton based notations within a specification. Specifically, we have 

— given a translation from stochastic automata to timed automata with dead- 
lines and shown which properties are retained; 

— presented two methods for model checking stochastic automata, the first 
of which builds regions from the automaton, and uses integration of the 
probability density functions and the second of which uses an approximation 
technique based on discretisation. 
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Translating stochastic automata to timed automata with deadlines means 
that, although the stochastic information is lost, we can analyse the composed 
specification for temporal properties to do with, for example, throughput within 
a certain time. 

The model checking methods cannot consider the composed specification, 
and must be restricted to the individual components, although the effects of the 
environment may be represented by the adversary chosen. 

The two model checking methods presented complement each other. The 
region method is best used when the size of the model to be explored is small, 
because the number of integrations to be performed goes up exponentially with 
the number of clocks. The discretisation method is more promising for larger 
models. It can produce upper and lower bounds on the probabilities, and is 
therefore best suited for queries such as “Does the probability of reaching a 
state s by a time t lie within the range [a, &]?” 

We are currently seeking to implement the second algorithm, and to integrate 
it with the LUSCETA [12] tool. We would also like to consider how to model 
check more general stochastic automata, and in particular to allow clocks to be 
set and used in any state. 

Acknowledgments. We are indebted to Pedro D’Argenio for supplying us with 
Definition 3 [9]. 
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Abstract. State-based refinement relations have been developed for use 
on the Object-Z components in an integrated Object-Z / CSP specifica- 
tion. However this rehnement methodology does not allow the structure 
of a specification to be changed in a refinement, whereas a full methodo- 
logy would allow concurrency to be introduced during the development 
life-cycle. In this paper we tackle these concerns and discuss rehnements 
of specifications written using Object-Z and CSP where we change the 
structure of the specification when performing the refinement. In parti- 
cular, we develop a set of structural simulation rules which allow a single 
Object-Z component to be refined to a number of communicating or in- 
terleaved classes. We prove soundness of these rules and illustrate them 
with a small example. 

1 Introduction 

There has been an increasing amount of work recently on combining state based 
languages such as Z[ll] and Object-Z [8] with process algebras such as CSP [4] 
and CCS [6]. The motivation for the work is that these combinations of languages 
provide a suitable medium for the description of complex systems which involve 
aspects of both concurrency and non-trivial data structures. Indeed, there are 
many application areas for such an approach including the obvious area of dis- 
tributed systems specification. 

The combination we are interested in here is the use of Object-Z together 
with CSP. This combination of languages has been investigated by a number 
of researchers including Smith [7], Fischer [2] and Mahony and Dong [5]. In 
this paper we work with the integration described by Smith [7] and Smith and 
Derrick [9,10], although the concerns we address are relevant to all combinations 
of these two languages. 

In the integration discussed here Object-Z is used to describe the components 
of a system, and these are then combined using CSP operators which describe 
how the components synchronise and communicate. For example, an elevator 
in a building might be described in this approach as {\\\n-Name^^^''^'n)\\LiftSys 
where User„ and LiftSys are given as Object-Z classes describing a user and 
the lift respectively, and the CSP operators || and ||| describe the interaction 
between these components. The combined notation benefits from reusing existing 
notations, being relatively simple and having a well-defined meaning given by a 
semantics based upon the failures-divergences semantics of CSP. 



W. Grieskamp, T. Santen, and B. Stoddart (Eds.): IFM 2000, LNCS 1945, pp. 194—213, 2000. 
(c) Springer- Verlag Berlin Heidelberg 2000 
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Of course as well as specifying systems we need a method of developing 
them, and there has been considerable work on refinement for both state-based 
languages and process algebras. This work has been applied to the combina- 
tion of Object-Z and CSP by Smith and Derrick [9,10] who develop state-based 
refinement relations for use on the Object-Z components within an integrated 
specification. Because Object-Z classes have been given a CSP semantics in the 
combined language, the refinements are compositional so that when a single 
Object-Z component is refined then so is the overall Object-Z / CSP specifica- 
tion. For example, if we refine the single LiftSys component to LiftSys2 then 
application of the theory tells us that {\\\n-Name Usern)\\LiftSys2 will be a refine- 
ment of {\\\r,..NameUsern)\\LiftSyS. 

However, the rules presented in [9,10] do not allow the structure of the spe- 
cification to be changed in a refinement. That is, only single Object-Z classes 
can be refined individually and therefore the structure of the specification, and 
in particular the use of the CSP operators, has to be fixed at the initial level of 
abstraction. This is clearly undesirable and in this paper we provide a means to 
refine the very structure of a specification written in the integrated notation. 

In particular, we develop refinement rules that allow us to refine a single 
Object-Z class into a number of communicating or interleaved classes. For ex- 
ample, we show how to refine the class LiftSys into a parallel composition of a 
class Lift, representing the lift, with a class Con, representing the lift controller. 
This approach therefore allows concurrency to be introduced during refinement 
as and when appropriate rather than having to fix the eventual structure of the 
implementation early in the development life-cycle. Similar concerns have been 
addressed by Fischer and Wehrheim [3], however there the emphasis was on 
using model checking in order to demonstrate refinement between specifications 
with different structures. Our work compliments this work nicely. 

This paper is structured as follows. In Sections 2 and 3 we discuss the inte- 
gration and refinement of specifications written using Object-Z and CSP. Then 
in Section 4 we look at refinements between specifications where we change their 
structure, and we develop rules for introducing the CSP parallel operator ]]. 
These rules are illustrated using the elevator case study. In Section 5 we derive 
similar rules for the CSP interleaving operator |||. We conclude in Section 6. 



2 Combining Object-Z and CSP 

In this section we discuss the specification of systems described using a combi- 
nation of Object-Z and CSP. In general the specification of a system described 
using these languages comprises three phases. The first phase involves specifying 
the components using Object-Z, the second involves modifying the class inter- 
faces (e.g. using inheritance) so that they will communicate and synchronise 
as desired, and the third phase constructs the final system by combining the 
components using CSP operators. 

Since all interaction of system components is specified via the CSP operators 
a restricted subset of Object-Z is used. In particular, there is no need for object 
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instantiation, polymorphism, object containment nor any need for the parallel 
or enrichment schema operators. Similarly not all CSP operators are required. 
For example, neither piping nor the sequential composition operator are needed. 
These restrictions help simplify the language and its semantic basis considerably. 



2.1 Example - A Lift System 

As a simple example we consider the classic lift case study [3] . The components 
of our system will be the users and the elevator system, and both are specified 
by Object-Z classes. To do so let Name denote the names of all possible users 
of the system, and suppose the available floors in a building are described as 
follows. 

minFloor , maxFloor : N 
minFloor < maxFloor 



Floor == minFloor ..maxFloor 

A single user is capable of one operation: to request a lift to a floor. The 
state variable requested is the set of all floors requested by the user. 

User 

I name : Name 



requested : P Floor 

Init 

requested = 0 

Request 

A{requested) 
r! : Floor 

requested' = requested U {r!} 



Our initial specification also contains the Object-Z class LiftSys which de- 
scribes an abstract view of the elevator system. The class consists of four opera- 
tions: Request models requests for the lift being made by customers, CloseD and 
OpenD model the closing and opening of the lift doors respectively, and Move 
describes the movement of the lift inside the shaft. Which request is serviced 
next is non-deterministic ~ any valid request is potentially chosen. 

Status ::= open \ closed \ stop 
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LiftSys _ 



req : P Floor 
pos : Floor 
door : Status 


Tnit 


req = Qi f\ pos = minFloor A door = open 


Request 


Close D 


A{req) 

/? : Floor 


A(door) 


req yf 0 

door = open A door' = closed 


req' = req U {/?} 


OpenD 


Move 


A{door) 


A{req, pos, door) 
/! : Floor 


door = stop A door' = open 


door = closed A door' = stop 

pos' € req 

req' = req \ {pos'} 

pos' = /! 





To specify the complete system we combine the components together in a 
way which captures their interaction. If we define f7ser„ to be the User class 
with name instantiated to n [7], then this interaction is given by 

Building = {\\\^,Manve^s^^n)WftSys 

which describes a single lift with which a number of users can independently 
interact. 

2.2 The Semantic Model 

Combined Object-Z and CSP specifications are given a well-defined meaning by 
giving the Object-Z classes a failures-divergences semantics identical to that of 
a CSP process. In a failures-divergences semantics a process is modelled by a 
triple (d., F , D) where A is its alphabet, F its failures and D its divergences. 
The failures of a process are pairs (t,X) where t is a finite sequence of events 
that the process may undergo, and X is a set of events the process may refuse 
to perform after undergoing t. 

To give Object-Z classes a failures-divergences semantics the failures of a 
class are derived from its histories, that is from the Object-Z semantic model of 
a class [10]. 

In doing so Object-Z operations are mapped to CSP events using the fol- 
lowing function which turns an operation op with assignment of values to its 
parameters p to the appropriate event: 
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event{{op,p)) = op.p{p) 

The meta-function (3 replaces each parameter name in p by its basename, i.e., 
it removes the ? or !. Thus the event corresponding to an operation (op,p) 
is a communication event with the operation name op as the channel and an 
assignment of values to the basenames of the operation’s parameters as the 
value passed on that channel. For example, the event corresponding to a user 
requesting a floor / is Request. {{r , f)}. 

Since Object-Z does not allow hiding of operations (hiding is only possible 
at the CSP level), divergence is not possible within a component. Therefore a 
class is represented by its failures together with empty divergences. 

As well as giving a well-defined meaning to a combined Object-Z / CSP 
specification, the semantics also allows a coherent theory of refinement to be 
developed. We discuss this in the next section. 



3 Refinement in Object-Z and CSP 

With our integrated semantics, refinement is based on CSP failures-divergences. 
Thus a specification C is a refinement of a specification A if 

failures C C failures A and divergences C C divergences A 

and if we are considering a single Object-Z component we need consider only 
the failures since its divergences will be empty as noted above. 

However, calculating the failures of a system is not practical for anything 
other than small specifications. To make the verification of refinements tractable 
we can adapt state-based verification techniques for use in our combined nota- 
tion, and in particular adapt the idea of upward and downward simulations used 
in Z [12]. This allows refinements to be verified at the specification level, rather 
than working explicitly in terms of failures, traces and refusals at the semantic 
level. 

The use of simulations between Object-Z components in the integrated not- 
ation is described by Smith and Derrick in [9,10]. In a simulation, a retrieve 
relation Abs links the abstract state (AState) and the concrete state (CState), 
and, for example, the definition of a downward simulation is as follows. 

Definition 1 Downward simulation 

An Object-Z class C is a downward simulation of the class A if there is a retrieve 
relation Abs such that every abstract operation AOp is recast into a concrete 
operation COp and the following hold. 

DS.l \/ AState; CState • Abs => {preAOp pre COp) 

DS.2 y AState; CState; CState' • Abs A COp {3 AState' • Abs' A AOp) 
DS.3 V CInit • 3 Alnit • Abs 
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Not all refinements change the state space, those that do not are called 
operation refinements as opposed to data refinements and these can be verified 
with a retrieve relation which is the identity (thus simplifying the refinement 
rules). 

The simulation rules allow a single Object-Z class to be refined by another. 
For example, we might refine the LiftSys component to LiftSys2. This new lift 
system is identical to the initial specification except that our Move operation is 
more deterministic and chooses the nearest requested floor instead of an arbitrary 
one. 



LiftSys2 



Move 

A{req, pos, door) 

/! : Floor 

door = closed A door' = stop 

pos' € req A ~'(3p : req *1 pos — p |<| pos — pos' |) 
req' = req \ {pos'} 
pos' =/! 



This refinement can be verified in the standard way using a downward simu- 
lation, and since simulations are together sound and complete with respect to 
CSP failures-divergences refinement, (|||„.jvame ^ refinement 

of {\\L.NameUserr,)\\LiftSys. 

However, this refinement is between single Object-Z classes and simulations 
do not allow us to change the overall structure of the specification. To understand 
the problem consider the following example. 



3.1 Example - Changing the Structure of the Lift Specification 



In an implementation we wish to refine the lift system into two separate com- 
ponents (a lift and a controller) which reflect more accurately the underlying 
physical configuration. The Lift class will control the position and movement of 
the lift, whilst the controller Con will marshal the requests and determine the 
next floor that the lift should service. 

The Lift class consists of a position {pos), a door and a current target, and the 
class Con keeps track of the current requests {req). The two classes communicate 
in order to determine the current position and the new target floor. 

The Lift class is as follows. 
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Lift 



pos, target : Floor 
door : Status 
target -received : B 

Init 

pos = minFloor A door = open A -> target -received 



SetTarget 

A{target, target-received) 
fl ,pos\ : Floor 

/? = target' A pos! = pos 
door = open 

-■ target -received A target -received' 



CloseD 

A{door) 

target -received 

door = open A door' = closed 



OpenD 

A{door) 

door = stop A door' = open 



MoveOneFloor 

A{pos) 

door = closed A pos target 
pos > target pos' = pos — 1 

pos < target pos' = pos + 1 



Move 

A(door, target -received) 

/! : Floor 

door = closed A door' = stop 

-< target -received' 

pos = target A / ! = pos 



The controller accepts requests and determines which floor the lift should 
go to next. Now, instead of being completely non-deterministic, the floor closest 
to the current position is chosen. To achieve this, the two classes communicate 
when performing the SetTarget operation. A similar communication takes place 
in the Move operation to determine which floor has been reached. We have also 
changed the granularity of Move from LiftSys by using MoveOneFloor to move 
the lift one floor at a time. Since Object-Z operations are blocked outside their 
preconditions, MoveOneFloor can only happen a finite number of times in a row. 

Note also that neither class contains the complete temporal ordering of ope- 
rations. This will be determined by the final synchronisation between the two 
classes. 
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Con 



req : P Floor 
target^sent : B 



Init 

req = 0 A ~<target-sent 

Request 

A{req) 

/? : Floor 

req' = req U {/?} 



CloseD 

target^sent 



SetTarget 

A{target-sent) 

/!, posl : Floor 

—'target_sent A target_sent' 

/! G req 
-■(3 p : req • 

I posl — p I < I posl — /! I ) 

Move 

A{req, target^sent) 

/? : Floor 

req ^ 0 

reg' = req \ {/?} 

-1 target^sent' 



It is then possible to show (e.g. by a calculation of failures-divergences) that 
LiftSys is refined by {Lift\\Con) \ {SetTarget, MoveOneFloor}^ . However, we 
cannot use simulations to verify the refinement. Furthermore, if we compare the 
LiftSys component with those given by Lift and Con we cannot even claim that 
individually the latter classes refine LiftSys. In particular, 

— the classes are not conformal, i.e. neither Lift nor Con contain all the operati- 
ons in LiftSys, yet they also contain additional operations such as SetTarget] 

— the new operations have additional inputs and outputs, and 

— the behaviour of the operations is different, e.g. the preconditions have been 
changed. 

Yet clearly LiftSys is refined by {Lift\\ Con)\{ Set Target, MoveOneFloor} , and 
what we seek to do is to derive state-based techniques that allow us to verify 
refinements like these without having to expand the synchronisation between the 
two classes and then calculate their failures. The next section discusses how we 
can do this. 

^ Throughout this paper we use the shorthand C \ {Op} to denote the hiding of all 
events corresponding to the operation Op. In general, the names of these events 
will consist of, as well as the name of the operation, a value corresponding to the 
mapping of the operation’s parameters to their values. 
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4 Structural Refinement 

In this section, we present simulation rules that allow us to prove refinements 
between Object-Z classes and CSP expressions involving more than one Object- 
Z class. Specifically, we look at rules for introducing the CSP parallel operator 

II- 

In Smith and Derrick [9,10], simulation rules which correspond to failures- 
divergences refinement were presented for refining an Object-Z class to another 
Object-Z class. To build on this work, we show, in this section, how to construct 
an Object-Z class which is semantically equivalent to a CSP expression involving 
parallel composition and hiding. This constructed class, and hence the equivalent 
CSP expression, can be shown to be a refinement of another class using the 
existing simulation rules. 

From the relationship between the schemas of the constructed class and those 
of the component classes of the CSP expression, we can also re-express the 
existing simulation rules in terms of schemas of the component classes. 

Figure 1 illustrates the process. We wish to refine a class A into (D || B) \ 
{xi, . . . , Xnj- To do so we show that D || B is failures-divergences equivalent to 
the Object-Z class E and that E \ {xi, . . . , Xn} is failures-divergences equivalent 
to the class C , and then, from the existing simulation rules, we derive alternative 
simulation rules to show that C is a downward simulation of A. The usefulness of 
the approach is that these alternative rules are expressed in terms of the original 
classes B and D, thus these rules allow us to verify the refinement without 
constructing the semantically equivalent class C . 



A 





Figure 1. Approaches to refinement 

In Section 4.1 we show how to construct the semantically equivalent class and 
in Section 4.2 we derive the simulation rules in terms of the component classes of 
the CSP expression. In Section 4.4 we prove the refinement of the Lift example 
from Section 3. The ideas are extended to the CSP interleaving operator |j| in 
Section 5. 



4.1 Constructing an Equivalent Class 

Our approach works for refinements of a class A into specifications of the form 
{D II 5) \ {xi, . . . , a;„} where classes D and B and events xi,. . . ,Xn are restricted 
as follows. 
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1. The variables declared in the state schema of class D are distinct from those 
declared in the state schema of class B . 

2. Any operations common to D and B (i.e. they have the same operation 
name) have parameters with identical basenames (i.e., apart from the ?’s 
and !’s). 

3. Each hidden event f G 1 . . n, must, in one of the classes D or B, occur 
a finite number of times immediately before a visible event y corresponding 
to one particular operation and not at any other time. 

In such cases, the finite sequence of hidden events followed by the event y 
represents an operation refinement of an event y of the abstract specification. 

4. When an operation name is shared by D and 5, an input in one of the 
operations with the same basename as an output in the other cannot be 
constrained more than the output. That is, given that Op in D has input xl 
and predicate p and Op in B has output x\ and predicate q, the following 
must hold. 

3 BState, BState' • q ^ 3 DState; D State' • p[x\/xl\ 
where DState and BState are the state schemas of classes D and B respec- 
tively, and p[x\/xl] is the predicate p with all free occurrences of xl renamed 
to x\. 



These restrictions are in fact entirely natural consequences of the events 
Xl, ... ,Xn acting as a communication medium between the two classes. 

Restriction 1 allows us to derive simulation rules expressed as rules on the 
two separate classes. Restriction 2 says that operations common to D and B 
will communicate on common channels, and restriction 3 stops divergence due 
to infinite sequences of hidden events. 

Restriction 4 allows us to construct an equivalent class by combining same- 
named operations with the Object-Z associative parallel composition operator 
II ! [8]. This operator conjoins its argument operations and renames any inputs 
in one operation for which there exists a common-named output in the other 
operation to an output. The common-named parameters are hence identified in 
the conjoined operation and exist as an output. 

To see why the restriction is needed, consider the following same-named 
operations from classes D and B. 



Op 

xl : N 



a;? ^ 5 



Op 

x\ : N 



x\ ^ 10 



When combined, the operations communicate via their parameters. The predi- 
cate of the operation from D, that with the input, places a stronger condition 
on the communicated value than the predicate of the operation from B (thus re- 
striction 4 is not satisfied). The result is that the combined operation can occur 
with the communicated value less than or equal to 5. 

Now consider refining the operation in B to the following. 
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Op 

x! : N 



5 < x! < 10 



This is possible since refinement allows conditions on outputs to be strengthened 
[10] . However, now the combined operation can never occur since there is no value 
of the communicated variable which satisfies both the operation in D and the 
operation in B. Hence, despite the individual classes D and B being refined, the 
resulting equivalent class is not refined (since we have effectively increased the 
refusals for any trace after which Op could have been performed). Restriction 4 
prevents this situation from occurring. 

We will now show how to construct an equivalent class C for the CSP expres- 
sion {D II R) \ {xi, . . . , x„} by considering first parallel composition and then 
hiding. 



Parallel composition. Consider classes D and B below where € N and 

j < b 



D 

DState 

DInit 

Opi 



B 

BState 

BInit 

Opi-j+i 



Opi 



Opk 



When i ^ 0, the classes share the operation names Opi-j+i . . . Opi. 

The parallel composition of classes D and R, D || R, is semantically equiva- 
lent to the following class. 

E 

DState A BState 
DInit A BInit 
Opi 



Opk 



where for each n : 1. .i—j, Opn is defined as in D, and for each n : i + 1. .k, Opn 
is defined as in R, and for each n ■. i — j + 1 .. i, Opn is the associative parallel 
composition of the definition in D with the definition in R, i.e. D.Opn Hi B.Opn- 
Therefore, for each n : i — j + 1 . . i, due to the DState and BState decla- 
ring distinct variables (restriction 1), Op„ in E transforms those variables from 
DState according to the operation Opn of D and those variables in BState ac- 
cording to the operation Opn of R. Furthermore, Op„ in E has parameters with 
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identical basenames to those in Opn of D and B. Therefore, the alphabet of E 
is the union of the alphabets of D and B. 

To see why the constructed class E is equivalent to D || 5, consider deriving 
the failures of E by the approach outlined in [10]. The failures of E are all traces 
s and refusal sets X U Y where 

— s is a trace comprising events corresponding to operations Opi . . . Opk , 

— X and Y are sets of events corresponding to operations in D and B respec- 
tively, 

— after s, since DState is only changed by events corresponding to operations 
of D (due to DState and BState declaring distinct variables), X includes only 
those events that can be refused by D after undergoing trace s restricted to 
the alphabet of D, 

— similarly, Y includes only those events that can be refused by B after un- 
dergoing trace s restricted to the alphabet of B. 

Hence, 

failures{E) = {s,X U T j s £ alphabet(D) U alphabet(B) 

A (s > alphabet {D) , X) £ failures{D) 

A (s > alphabet(B), Y) £ failures{B)} 

Since an Object-Z class has no divergences, this is equivalent to the failures of 
(D II B) as given by Hoare [4]. 

Hiding. Consider the class E below where Op 2 occurs m : N times before each 
occurrence of Op^ and not at any other time. 

E 

Estate 

EInit 

Opi 

Op2 

Opz 



The CSP expression which hides Op 2 in E, i.e., E \ {Op 2 }, is semantically 
equivalent to the following class^. ‘Ops’ denotes the name of the operation Ops 
in E, as opposed to its definition denoted simply by Op^. The effect of ‘Opa’ 
is to perform Op2 \ {xi, . . . ,Xn) rn times in sequence followed by the original 
operation Op^. (xi,. . . ,Xn are the parameters of Op 2 -) 

C 

Estate 

EInit 

Opi 

‘Op 3 = : N I J < m • Op2 \ {xi , . . . ,a:„)) § Ops 

^ Note that the syntax for hiding operation parameters in Object-Z, Op \ (x), is 
different to that of hiding events in CSP, P \ {a;}. 
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Consider deriving the failures of the constructed class C by the approach 
outlined in [10]. The failures of C are all traces t and refusal sets X where there 
exists a failure (s, Y) of E such that s restricted to the events of C is t, and Y 
includes, as well as the events in X, all events corresponding to Op 2 - 
Hence, 

failures{C) = {s > alphabet{C), X \ (s,X U {Op 2 }) G failures{E)} 

Since an Object-Z class has no divergences, this is equivalent to the failures of 
E \ {OP 2 } as given by Hoare [4]. The definition can be extended for hiding of 
multiple operations in the obvious way. In fact, what we are using here is a 
restricted form of weak refinement [1] where we compare in the refinement an 
abstract operation with a concrete one preceded by a finite number of internal 
operations. 



4.2 Deriving the Simulation Rules 

Given a refinement {D jj 5) \ {zi, . . . , a;„} of H, we could verify the refinement 
by constructing an equivalent class as outlined in Section 4.1 and using the 
simulation rules of Smith and Derrick [10]. However, it is preferable not to have 
to construct an equivalent class but to instead have rules which refer directly 
to the schemas of the component classes D and B. We now show how we can 
derive these rules. 



Parallel composition. We begin by considering the case where we have par- 
allel composition only (and no hiding). For operation names occurring in only 
one component class, the operation given this name in the constructed class is 
identical to that in the component class in which it occurs. Hence, the simulation 
rules are unchanged. 

For shared operations, however, the operation in the constructed class is the 
associative parallel composition of the operations in the component classes. In 
this case to verify the refinement we can use the downward simulation rules 
DS.l and DS.2 which, for the communicating operations, require that: 

DS.l' y A State] DState] BState • pre AOp pre {DOp |]i BOp) 

T)S.2' M AState] DState\ BState] DState'] BState'* 

{DOp |]i BOp) {BAState' • AOp) 

where DState and BState, and DOp and BOp are the two component states and 
operations respectively. 

These rules still involve an operation, DOp |]i BOp, to be constructed from 
the two classes. However, we can by-pass the necessity to construct this opera- 
tion as follows. Consider the following operations DOp and BOp {p and q are 
predicates). 
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where x and y are the state variables 
distinct (by restriction 1). 

The associative parallel composition 



BOp 

y,y' ■■ Y 
z! : z 



q 



of the two component classes and are 
of these operations is 



DOp II ! BOp 

A{x,y) 

x, x' \ X 

y, y' -Y 
z! : Z 



p\z\jzT\ A q 



where p[z\/zl] is the predicate p with all free occurrences of z? renamed to z\. 
Hence we can simplify the precondition calculation as follows: 

pre{DOp ||i BOp)= 3x' : X,y' : Y,z\ : Z • p\z\j zT\ A q 

= 3x' : X ,y' : Y , z\ : Z , w\ : Z • p[w\/z7] A q 
[by restriction 4] 

= {3x' : X ,w\ : Z • p[w\/z7]) A (3y' : Y; z\ : Z • q) 

[since p[w\/zl] and q refer to distinct variables] 

= pve DOp[w\ / zl] A preBOp 

In addition, we have 

DOp ||i BOp = DOp[z\/ zl] A BOp 

Extrapolating to the general case, we have the following. 

pre(DOp |[t BOp) = pre DOp[wi!/zi?, . . . , w„!/z„?j 
A 

pre BOp [lCyi-|_i !/ Z^_|_1 ?, ■ • ■ , !/ Zn-\-m^] 

DOp |[t BOp = D0p[zi!/2i?,...,z„!/z„?] 

A 

BOp[Zn+ll/ 

Hence, the simulation rules can be re-expressed as follows. 

Definition 2 Parallel downward simulation 

A CSP expression D \\ B is an operation downward simulation of the Object-Z 
class A if D and B satisfy restrictions 1, 2 and j (above) and the following hold. 
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PS. 1 \/ AState; DState; B State • 

preAOp pre DOp[wi\ / z\l , . . . , w„!/z„?] 

A 



preBOp[wn+i\/Zn+i^., ■ • ■ , w„+„!/z„+„?] 
PS.2 'i AState] DState] BState] DState'] B State' • 

DOp[zi\/Zil,...,Zn\/Zn'?] 

A 



BOp [ 2 ^ 71 - 1-1 , . . . , Zji + m}. / 2 tj , - 1 - 777 ?] 

{3AState' • AOp) 

PS. 3 V DInit A Blnit • (3 Alnit • irwe) 



Hiding. When we have hiding (as well as parallel composition) , for those parti- 
cular operations which can be preceded by a finite sequence of hidden operations 
(as required by restriction 3), we replace the operation in the simulation rules 
with a sequential composition comprising the sequence of hidden operations and 
the operation. For example, if Opz can be preceded by m : N occurrences of a 
hidden operation Op2 (as in the example of Section 4.1), we replace Op^ in the 
simulation rules by (gZ : N | z < m • Op2 \ (xi, . . . , Xn)) g Ops. 

To illustrate this, we consider two cases. The first when one of the hidden 
events Xi occurs in just one of the classes D and B and has no parameters, and 
the second when it occurs in both classes and has parameters for communication. 
Our lift example illustrates both: MoveOneFloor only occurs in Lift and has no 
parameters whereas SetTarget occurs in Lift and Con and the parameters /? 
and pos!, and /! and pos? respectively, are used to communicate values. 

Case 1. Suppose, without loss of generality, an event x occurs in just one 
class D in {D\\B) \ {x} and can occur m times in a row where m G 5 C N. 
Let us denote this operation by Dx. Given Dx has no parameters, we have 
to show a simulation between AOp and Lnto g {DOp jji BOp), where Lnto is 
[] m : S • {gi : N \ i < m • Dx). 

Since the state spaces of D and B are disjoint this can be re-written as 
{Into g DOp) III BOp, and thus the simulation rules for the operations require 
that: 

PS.l V'TlS'tate; DState] B State • 

pre.40p pre{Lnto g DOp[wil/zi 7 , ..., wA/zn^]) 

A 

pveBOp[Wn+l\hn+C, ■ ■ • , ^77-^777!/ 

PS.2 y AState] DState] BState] DState'] B State' • 

{Into 9 DOp[zi\/zi 7 , ..., 2771/277?]) 

A 

BOp [277-1-1!/ ^n-t-l?; • ■ • ; ^n-t-m!/ ^n-t-m?] 

=> { 3 AState' • AOp) 

Case 2. Suppose an event x occurs in both classes (e.g. in order to perform a 
communication as in SetTarget) in (D\\B) \ {x} and that it communicates over 
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channel y. Let Dx denote the operation x in class D etc. Then we have to show 
a simulation between AOp and {{Dx ||i Bx) \ {?/!}) § {DOp ||i BOp). 

Since the state spaces of D and B are disjoint and assuming y \ does not occur 
as a parameter in DOp and BOp, this can be re-written as {{Dx q DOp) ||i {Bxg 
BOp)) \ {y!}. Since hiding distributes through pre, the simulation requirements 
become: 

PS.l V^S'tate; DStatf, B State • 
pre AOp 

3 y! • pre{Dx § DOp[wi\/zi7, wA/z„7]) 

A 

pvei{Bx 9 BOp)Wn-\-A / , . ■ . , j Zn-\-viy-\) 

VS.2^ AState] DState; BState; DState'; B State' • 

3 y! • {{Dx § DOp[zi\/zil, z„!/z„?]) 

A 

{Bx 9 BOp)Zn-\-A/ Zn-\-l^ , ■ • ■ , ^n+m 
=> {BAState' • AOp) 

These rules can be generalised to multiple events and parameters, as well as to 
the case when the hidden event x occurs more than once before its corresponding 
visible event. 

4.3 Data Refinement 

In this section we generalise the rules to cover data refinement. That is, we 
consider the case when the state space of A is changed when refining this class 
to {D \\ B) \ {xi, . . . ,Xn}, and as noted in Section 3, a retrieve relation Abs is 
used in these circumstances to verify the simulation rules. Our task here then 
is to determine how this impacts on the structural refinement rules given in 
Definition 2. 

In taking a change of data into account we first note that the construction 
of the single class C which is semantically identical to {D || B) \ {x\, . . . ,Xn} 
is unchanged. Hence the impact of data refinement only occurs in using the 
simulation rules when verifying the refinement from C to the original component 
class A. The rules for parallel composition are easily expressed as follows. 

PS.l DState; BState* 

Abs => {pre AOp pre DOp[wi\ / z\l , . . . , 

A 

pre BOp !/ Zji-\.\t , . . . , j Zji-\.jyi^) ) 

AState; DState; BState; DState'; BState'* 

Abs A DOp[zi\/zil , . . . ,z„!/z„?] 

A 

BOp[z„+l\/ Zn+l^ , . . . , Z’a-\-m}'l 

=> (3 AState' * AOp A Abs') 

PS. 3 V DInit A Blnit * (3 Alnit * Abs) 
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4.4 Example 

Using these rules we can now show that LiftSys is refined by {Lift\\Con) \ 
{SetTarget, MoveOneFloor}. To do so we must check that the decomposition 
satisfies the restrictions 1-4 outlined at the start of Section 4.1, and then verify 
conditions PS. 1-3. 

Restrictions. Restriction 1 clearly holds. For restriction 2 we have to compare 
parameters in SetTarget, CloseD and Move between the two classes Lift and 
Con. In each case the basenames in the pairs of operations are the same (e.g. / 
in Move). 

The hidden operations are SetTarget and MoveOneFloor . A Boolean variable 
in each class has been inserted to ensure that SetTarget happens once, but only 
once, before each (visible) CloseD operation. Restriction 3 therefore holds for 
SetTarget. 

MoveOneFloor is slightly more complicated, because in effect the refinement 
has decomposed the Move in LiftSys into a finite number of MoveOneFloor 
operations followed by a Move in the classes Lift and Con. However, restriction 
3 is still satisfied because MoveOneFloor can only happen a finite number of 
times (until the lift reaches its target), after which a Move must happen. 

We also have to check the restrictions on the predicates given by 4. Thus, for 
example, for the Move operation we have to check: 

3pos, target, door,pos', target', door' • 
door = closed A door' = stop 
pos = target A / ! = pos 

3 req, close, req', close' • req yf 0 A req' = req \ {/!} 
which, since no constraints are being placed on the input, is trivially satisfied. 

Simulation rule PS.l. For each operation in LiftSys we have to show that 
either it is a standard refinement if it occurs in just one class, or show that PS.l 
holds if it occurs in both classes. 

For the former. Request and OpenD are identical in the refinement, and both 
operations appear in just one class. 

For operations CloseD and Move we are going to have to demonstrate that 
PS.l holds, remembering that we have to take into account the hidden operati- 
ons SetTarget and MoveOneFloor in doing so. 

Consider the Move operation. The MoveOneFloor hidden event can occur a 
finite number of times before it, thus according to the above we need to con- 
sider the effect of [] m : (0 . . maxFloor — minFloor) • {gi : N \ i < m • 
MoveOneFloor) gMove). Although this sounds complicated, it is not difficult in 
practice. Simply looking at the behaviour of MoveOneFloor and Move together 
shows us that we have to verify (with Abs equating the variables req, pos and 
door of LiftSys with those of Lift and Con): 
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Ahs A pre LiftSys.Move 

pre Lift. { |] m : (0 . . maxFloor — minFloor) • 

{gi : N \ i < m • MoveOneFloor) § Move) 

A 

pre Con. Move 

and this boils down to the trivial 

door = elosed A req ^ 0 {door = closed) A {req ^ 0) 

Simulation rule PS. 2. In a similar fashion we must show PS. 2 holds for both 
CloseD and Move. For example, for CloseD we need to show that 

Con.{SetTarget g CloseD[pos\ / posl]) A Lift.{SetTarget § CloseD[f\/f7]) 

=> {3 LiftSysState • LiftSys. CloseD) 

This amounts to showing that 

/! £ req A ~'(3p : req *1 posl — p |<| posl — /! |) 
door = open A door' = closed A /! = target' A pos! = pos 

3 LiftSysState • req 7^ 0 A door = open A door' = closed 
which again is clearly true. 



Simulation rule PS. 3. This amounts to showing that together the initialisa- 
tions of Lift and Con imply the initialisation in LiftSys. 

Therefore LiftSys is refined by {Lift\\Con)\{SetTarget , MoveOneFloor} , and 
since the hidden events do not occur in Usern, (|||„-jvame User„)\\ LiftSys is refined 
by i\\\n-.NameUsern)\\{Lift\\Con) \ {SetTarget, MoveOneFloor}. 

5 Rules for Introducing Interleaving 

We can also derive rules which allow us to refine a class A into D ||| 5, by a 
similar derivation to the above. Given a CSP expression involving interleaving of 
the form D 1 1 1 B, an equivalent class can be constructed following the approach 
for parallel composition except that the Object-Z choice operator [8], denoted [], 
is used in place of associative parallel composition to combine common-named 
operations. (Reasoning in terms of failures similar to that for parallel composition 
can be used to show why this is the case.) Because there is no communication 
between the components D and B there is no need to impose restriction 4 that 
was needed for the parallel composition operator. 

The choice operator disjoins its arguments adding first to each a predicate 
stating that variables in the Z\-list of the other operation which are not also 
in their Z\-list remain unchanged. It also has a requirement that the combined 
operations have the same parameters. 
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Given the operations, DOp and BOp of Section 4.2, therefore, the operation 
in the equivalent constructed class is 

DOp 0 BOp 

A{x,y) 

x, x' : X 

y, y' ■■ Y 

z?,z! : Z 

(p A y' = y) 

V 

{q A x' = x) 



Hence, we can simplify preconditions as follows. 

pre{DOp [] BOp)= 3x' : X] y' : Y • {p A y' = y) \/ {q A x' = x) 

= {3x' : X; y' : Y • p A y' = y) 

V 

(3x' : X; y' : Y • q A x' = x) 

= {3x' \ X • p) \J {3y' ■. Y • q) 

[since y' is not free in p and x' is not free in q] 

= pre DOp V pre BOp 

In addition, we have 

DOp [j BOp= {DOp A[y' = y])\/ {BOp A [x' = a;]) 

= DOp V BOp 

since y is not in the Z\-list of DOp, and hence we implicitly have y' = y in DOp 
in the constructed class, and x is not in the Z\-list of BOp. 

Hence, the simulation rules can be re-expressed as follows. 

Definition 3 Interleaving downward simulation 

A CSP expression H |j| i? is an operation downward simulation of the Object-Z 
class A if D and B satisfy restrictions 1-2 and the following hold. 

15.1 \/ A State; DState; B State • pre AOp pre DOp \/ pre BOp 

15. 2 \/ A State; DState; BState; DState'; B State' • 

DOp V BOp {3 A State' • AOp) 

15. 3 V DInit A Blnit • (3 Alnit • true) 

Given restriction 3, these rules can be modified for hiding in exactly the same 
way as the parallel composition rules. They also extend to data refinement in 
the obvious way. 

6 Conclusions 

The purpose of this paper has been to present some refinement rules for deve- 
lopments where we change the structure of a combined Object-Z / GSP specifi- 
cation. 
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The simulation rules we have developed are sound, since we have verified 
them with respect to failures-divergences refinement, but they are clearly not 
yet complete. That is, there will be further refinements of structure that cannot 
be verified by application of Definitions 2 and 3. One further avenue for this 
research is to extend these rules to a set of complete structural refinement rules. 

One aspect that could be considered are the restrictions placed on the de- 
composition, and in particular, one could envisage relaxing the third restriction 
concerning when hidden events can occur. It is likely that a full generalisation 
would use the ideas of weak refinement [1] here to produce quite arbitrary com- 
bined classes. 

This work could also be extended to other combinations of Object-Z and 
CSP, such as those described in [2,5]. 
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Abstract. A formal framework for the design of distributed, message- 
passing programs from shared-variable parallel programs is presented. 
Based on a uniform semantic model for both paradigms and a trace-based 
refinement calculus, we show how a shared-variable parallel program can 
be refined into a distributed program. The calculus is used to introduce 
iteration, parallelism, and local channels, to replace access to shared 
variables by message-passing primitives, and to update the channels such 
that processes find the expected information on the expected channels 
at the right time. The methodology is illustrated with the development 
of a distributed implementation of an all-pair, shortest-paths algorithm. 



1 Introduction 

Despite their appealing performance-to-cost ratio and the increasing availability 
of tools, parallel computers still fail to have the expected impact on mainstream 
computing. A close look at the state of the art in parallel computing suggests at 
least two reasons: 

1. Parallel programming is inherently complex. Compared to sequential pro- 
gramming, the developer additionally must deal with, for instance, inter- 
ference, race conditions, process creation and termination, shared resources 
and consistency, synchronization and deadlock. Successful treatment of these 
issues requires knowledge about, for instance, the location, interconnection, 
and relative speeds of processors, and the location of and access to data. 
In parallel programs, efficiency in terms of explicit, fine-grained parallelism 
seems to exclude robustness, maintainability, and verifiability. 

2. The paradigms, patterns and formal models of program execution for various 
parallel architectures differ substantially. This lack of commonality makes al- 
most every task involving parallel programming very architecture-dependent. 
For instance, it is hard to move a program and verification efforts from one 
architecture to another. Typically, a program must be modified substanti- 
ally to take full advantage of, or even to execute on, a different architecture. 
In short, parallel programs usually are not portable. The loss of portability 
in turn limits the expected lifetime of parallel implementations and their 
economic viability. 



W. Grieskamp, T. Santen, and B. Stoddart (Eds.): IFM 2000, LNCS 1945, pp. 214—234, 2000. 
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Proof systems, program transformation frameworks and refinement calculi have 
been suggested to overcome the first problem, see e.g., [11,14,3,2,15,1]. In parti- 
cular, in previous work we have introduced a trace-based refinement calculus for 
shared- variable parallel programs [10]. The calculus supports the successive, for- 
mal derivation of shared- variable parallel programs from high-level specifications 
and has been used for the development of, for instance, versions of the Floyd- 
Warshall algorithm and the n-process tie-breaker algorithm for mutual exclusion 
that exhibit more parallelism than the standard textbook implementations [9]. 

To address the second problem, this paper extends our previous work men- 
tioned above by presenting a uniform semantic model for shared-variable and 
message-passing concurrency and by extending the refinement calculus to in- 
clude message-passing constructs. Modeling the two paradigms in the same se- 
mantic domain enables us to move easily between them. For instance, the reuse 
of an implementation using one paradigm for the development of another imple- 
mentation using a different paradigm becomes possible. In particular, we show 
how a shared-variable parallel implementation of an algorithm can be refined 
into an equivalent distributed message-passing implementation. The treatment 
of liveness properties is currently subject to further work, but initial results are 
promising. 

Sections 2 and 3 summarize the refinement calculus presented in [10]. Sec- 
tion 4 presents refinement rules for the introduction of iteration and parallelism. 
Section 5 shows how to model channels and the standard message-passing con- 
structs. Section 6 presents a detailed example. Section 7 discusses the treatment 
of liveness properties and Section 8 concludes. 



2 Syntax and Semantics of Programs 



We describe the language used to represent abstract specifications and executable 
programs. For convenience, all elements of this language will be called programs. 



Programs. Let Var denote the set of all program variables. An atomic state- 
ment has the form of Morgan’s specification statement V:[P, Q], where V C Var 
is a finite set of variables and P and Q are first-order predicates [12]. It de- 
scribes a single atomic transition transforming a state satisfying P into a state 
satisfying Q by just changing the variables in V. For instance, the statement 
{x}:[tt,x > 0] describes a random assignment to x. An idling, or stuttering, 
step is expressed as skip = 0:[tt,ft] where tt denotes true. To be able to refer 
to the value a variable held initially, that is, at the beginning of the transition, 
we reserve “hooked” variables a; in Q. If a predicate does not contain hooked 
variables it is called unary. Otherwise it is called binary. In a statement V : [P, Q ] , 
P must be unary, whereas Q may be unary or binary. The semantics of atomic 
statements is captured by characteristic formulas. 



216 J. Dingel 



Definition 1 . Characteristic formula 

The characteristic formula cfv-.[p^Q] of an atomic statement V:[P,Q] is given by 
cfv:[P,Q] = P A Vi G Var\V.L = f 

where P abbreviates the substitution of all free unhooked variables in P by their 
hooked counterpart and i is a metavariable that ranges over program variables. 
We interpret a binary predicate Q over pairs of states (s, s') where s assigns 
values to hooked variables and s' to the unhooked ones. Thus, (s, s') ^ Q iff 
replacing the hooked variables in Q by their values in s and replacing the un- 
hooked variables in Q by their values in s' makes Q true. □ 

More complex programs are built using sequential and parallel composition, 
disjunction, iteration, and hiding using the grammar below. We assume that 
every program variable x has a domain Dorrix of values associated with it. 

C ::= M:[P, Q] | Ci ; C2 | Ci V C2 | C1HC2 | C* | C“ | new a: = in C 

where v G Domx- The set of free variables fv{C) of a program C is defined 
inductively as usual with fv{V:[P, Q]) = V U fv{P) U fv{Q) as the base case. 

Transition Traces. Let s, s', Si G P denote states, that is, mappings from the 
set of program variables Var to values. Transition traces^ 

(■SO: Sq)(si, S]^) . . . (Sj, Sj) . . . 

have proven very useful for the definition of compositional models of shared- 
variable concurrency [13,7,4]. One such trace represents a possible finite or infi- 
nite “interactive” computation of a program in which state changes made by the 
program (from Si to s') are interleaved by state changes made by its environment 
(from s' to Si_|_i). The meaning of a program is given by a set of transition traces 
closed under two conditions: stuttering and mumbling. Brookes has used these 
conditions to achieve full abstraction — a desirable property indicating that, in- 
formally, the semantics is at the right level of abstraction [4]. They correspond, 
respectively, to reflexivity and transitivity of the — ^* relation in a conventional 
operational semantics. Given a set T of traces, the closure under stuttering and 
mumbling is the smallest set which contains T and satisfies: 

— Stuttering: if aj3 G then a(s, s)/3 G and 

— Mumbling: if a(s, s)(s, s')/3 G then a(s, s') (3 G . 

We now define a few operations on traces and sets of traces. The concatena- 
tion T\ ; T 2 and the infinite iteration operation are defined as 

Ti;T 2 = {a/3 I a G Ti A /3 G T 2 }^ 

T“ = |ao...a„... I Vf > O.tti G T}'^. 

^ Sometimes also called potential or partial computations or extended sequences. 



A Development Methodology for Parallel and Distributed Programs 217 



T* denotes the smallest set containing T and the empty trace, closed under 
stuttering, mumbling and concatenation, that is, T* = T" where T° = {e} 
and =T \ Fair parallel composition is modeled by fair interleaving of 

sets of traces 



T1WT2 = |J{ai||a2 I ai € Ti A 02 G T2}'!' 

where a\\(3 is the set of all traces built by fairly interleaving a and / 3 . One way 
to define o || /3 formally can be found in [ 4 ]. 

P = {7 I (ct,/ 3 , 7 ) G fairmerge} 
fairmerge = {L* RR* L)‘^ U (L U R)*A 
L = {((s,s'),e, (s,s')) I (s,s') G (r X 17)} 

R = {(e,(s,s'),(s,sO) |(s,s')G( 2 :xr)} 

A = {(o!,e,a) I a G (if X 27 )°°} 

U{(e,/ 3 ,/ 3 ) 1/3 G ( 27 x 27 )°°} 

where concatenation and iteration are extended to sets and triples of traces in 
the obvious way: AB = {a /3 | a G A A /3 G 33 } and (ai, 02, a3)(/3i, /32, / 3 a) = 
(ai/ 3 i, 02/32, 03/33). 

Local Variables. We use the notation [s|a: = v] to denote the state that is like 
s except that the value of x is updated to v. Let o = (sq) So)('®i5 ■®i) ■ • ■ • 

be a transition trace. The trace {x = v) a is like a except that x is initialized to 
V in the first state and that the value of x is retained across points of possible 
interference. More precisely, {x = v)a is 

([sola; = ?;], So)([si|a; = Sq(x)], s{) . . . ([sija; = s'_i(a;)], s') . . . 

The trace o\a; on the other hand describes an interactive computation like o 
except that it never changes the value of x. That is, a\x is 

(so, [s'o I X = So(a;)])(si, [s{ | x = Si(a;)]) . . . (sj, [s' | x = Si(x)]) . . . 

Definition 2. (Traces and executions) 

1 . The semantic function T maps programs to closed sets of finite and infinite 
transition traces and is defined as 

T[V:[P,Q ]1 = {(s,s') I s,s' G 27 ,(s,s') ^ c/y,[p,Qj}^ 
riCi;C2l= Tic'll ;r[C2l 
T[Ci VC2I = r[Ciiur[C2i 
rici||c'2i = r[ciii[ nc2] 
nc*j = {ncj)* 
nc“i = (r[c])" 

T|new a; = r; in C] = {o\a; | (x = v)a G T|C]}^. 
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2. A trace (sqj So)('51j ®i) • ■ • is interference-free if s' = s^+i for all i > 0. The 
executions £\C\ of a program C are given by 

= {a € TIC] I a is interference-free}. 

3. Let Cl Cr C2 and Ci =r C2 abbreviate T[Ci| C r[C2| and T|Cil = 

TIC 2 ] respectively. Similarly for £. □ 

The clause for new requires some explanation. The traces of new cc = ?; in C do 
not change the value of x and are obtained by executing C under the assumption 
that X is set to v initially and that the environment cannot change the value 
of X. Consequently, the value of a local variable cannot be changed outside its 
scope, nor can changes carried out inside the scope be observed on the outside. 
As an example, consider the following equivalence which follows directly from 
the definition of new and the closure conditions. 

new a: = 1 in a;:=a; -I- 1 ; y;=a; -I- 1 end = 7 - y:=2 

As we will see in Section 6, scope and locality make reasoning about parallel 
programs substantially more tractable. Knowing that a variable x is local, means 
that the environment cannot invalidate program properties involving x and that 
the environment cannot it be influenced by changes to x. Consider, for instance, 
the parallel composition 



new a; = 1 in Cl end HC 2 . 

Since x is local, program Ci cannot change the value of any occurrence of x in 
C 2 , while C 2 cannot change the value of any occurrence of x in Ci. 

The following proposition collects a few central properties of the semantics. 

Proposition 1. (Properties of T) 

1. If Cl C 7 - C 2 , then Cl Qs C 2 - 

2. Parallel composition is associative and commutative, that is, 

[Cl II C2] II C3 =r Cl II [C2 II C3] and Cl II C2 =r C2 II Cl. 

3. Informally, let a context E be given by a program with a “hole” . Trace 
inclusion is a congruence, that is, Ci C 7 - C 2 implies T[Ci] Cj- E[C 2 ] for all 
E. In other words, trace inclusion is preserved by all contexts. 

4. Due to the closure conditions, the semantics is invariant under the addition 
of finite stuttering, e.g., Ci ; skip* ; C 2 =r Ci ; C 2 and C || skip* = 7 - C. □ 

The proofs of full abstraction, associativity, commutativity and congruence can 
be found in [4]. Since parallel composition is commutative, we can abbreviate 
the n-ary parallel composition Ci || ... || C„ by |||^’ '’"'^Ci. 

Encoding Standard Programming Language Constructs. The standard 
constructs of a shared-variable parallel programming language are embedded 
into our setting through the following abbreviations. The await statement is 
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implemented using busy waiting. Let e be a expression whose value is defined if 
and only if the predicate def{e) holds. Moreover, let B he a, boolean expression. 



{B} 

skip 

x:=e 

if B then Ci else C2 
while B do C 
await B then :=ei ; . . . ; 



%:[def{B) AB,def{B) ^B] 

{tt} 

{x}:[def{e) , X =e] 
({B};Ci)V({-B};C2) 
{{{B}-,Cy-,{^B}) V {{B}-,Cy 
{a;i, . . . , Xn}-[B, Q] V {^B}‘^ 



where Q = xi =ei A . . . A =e„. Let C be a program in which * is a constant 
integer variable, that is, an integer variable that is only read and never assigned 
to. Also, let n be a natural number. Then, a for loop can be defined as 



for i = 1 to n do C = C[l/z] ; . . . ; C[n/z] 

where C[j/i] denotes the program that is obtained from C by replacing all free 
occurrences of i hy j. An array A with indices from 1 to n stands for a set of 
variables A[l] through A[n]. Assignments to an array variable with a constant 
index i are defined by 

A[i]-.= e = {A[i]}:[l < i < n A def{e), A[i] =e]. 

Note that the above assignment has no traces if the array index i is outside 
the array bounds or the expression e is undefined. A treatment of non-constant 
array indices can be found in [9] . Also note that our definition of the statement 
V : [P, Q] differs slightly from Morgan’s in [12]. There, the behaviour of V:[P, Q] 
in an initial state that does not satisfy P is completely arbitrary. Even non- 
termination is possible. In our setting, however, in initial states that do not 
satisfy P the statement E:[P, Q] exhibits no behaviour at all. Our encoding of 
the conditional statement, for instance, necessitates this deviation. 



3 Refinement 

A very natural notion of program approximation arises through transition trace 
inclusion. However, congruence implies that trace inclusion between two pro- 
grams Cl and C 2 implies that in all possible contexts the executions of Ci are 
contained in those of C 2 in the same context. Thus, whenever we want to do re- 
finement in a specific context, trace set inclusion typically is too strong, because 
it does not allow us to incorporate information about that particular context. 
Following Jones and Stirling [11,14] we will use assumption-guarantee reasoning^ 
to remedy this situation. 



Sometimes also called rely- guarantee or assumption- commitment reasoning. 



2 
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Definition 3. (Assumption-guarantee formulas) 

1. Let a = (sq; ■So)(®ii • be a transition trace, P be a unary predicate 
and r a set of unary predicates. We say that a satisfies the assumptions P 
and r, a \= assump{P,P), for short, iff the first state satisfies P and all 
predicates in P are preserved across all gaps along a, that is, 

— So 1= P, and 

— (s', Si+i) \=P'^ P' for all P' G P and for all 0 < i < length{a) 
where length(a) stands for the number of pairs in a minus 1. 

2. Let Q be a unary predicate and Z\ be a set of unary predicates. We say that 
a satisfies the guarantees Q and A, a \= guar{Q, A), for short, iff the last 
state in a (if it exists) satisfies Q and all predicates in A are preserved across 
all transitions along a, that is, 

— last{a) ^ Q, if a is finite and 

— (si, s') \=P'^ P' for all P' G A and for all 0 < i < length{a) 
where last{a) denotes the last state of a, if a is finite. 

3. C guarantees Q and A under assumptions P and P, [P, P] C [Q,A] for 

short, iff for all a G TIC], a ^ assump{P, P) implies a |= guar{Q, A). □ 

The following definition will allow us to express that the traces of a program 
are contained in those of another, if the environment satisfies certain assumptions 
and the changes to certain variables are ignored. 

Definition 4. (Relativized trace inclusion) 

Given programs C, C", a unary predicate P, a set of unary predicates P, and a 
program variable x, the notation 

CAtC {P,P,x) 

expresses that for all traces a G T|C'] such that 

— a \= assump{P, P), and 

— {x = v) a G T|C"| for some v G Dorux, 

there exists G T|C] such that 

— \= assump{P,P), 

— {x = v)(3 G T|C], and 

— a\x = P\x. 

Given a set of variables V, let C Aj- C' (P, P, V) be the obvious generalization. 

□ 

Our definition of refinement combines assumption-guarantee reasoning and 
relativized trace inclusion. 

Definition 5. (Refinement) 

Given unary predicates P and Q, sets of unary predicates P and A, and a set 
of program variables V C Var, we say that C refines C modulo V under the 
assumptions P and P and the guarantees Q and A, 

[P,P] C^vC' [Q,A] 



for short, iff 
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1. no variable in V occurs free in C, that is, fv(C) D V = 0, and 

2. C guarantees A under assumptions P and P, that is, 

[P, -T] C [tt, A] , and 

3. C guarantees Q and A under assumptions P and P, that is, 

[P,P] C' [Q,A], and 

4. we have C 2r C (P, P,V). □ 

Informally, the refinement [P, P] C C' [Q, A] expresses that assuming an 
initial state that satisfies P, and a parallel context that preserves the predicates 
in P, then every transition of C can be matched by C modulo the changes to 
variables in V, every transition of C and C will preserve the predicates in A, 
and whenever C and the parallel context terminate, they will do so in a state 
satisfying Q. Consider, for example, 

[a; = 1, {a; = 1, a; = 2}] x\=x + 1 >-([, x\=2 [a; = 2, Preds( Var\{a;})] 

where Preds{V) denotes the set of all unary predicates P with free variables in V, 
that is, fv{P) C V. If the initial state satisfies a; = 1 and the parallel environment 
preserves the predicates a: = 1 and a; = 2 , then every transition by a ::=2 can be 
matched exactly by a;:=x+ 1 , the final state satisfies a; = 2 and every transition 
by a;:=2 and x:=x + 1 preserves all predicates in Preds{Var\{x}). For another 
example, consider 

[a:=lAj/=lAt = 0,{a; = l,?/=l,t = 2,a; = 3}] 
skip ; a;:=2 • X + y t:=2 ■ x •, x:=t + y 
[x = 3 A y = 1, Preds{ Var\{x, t})] . 

Here, the matching between transitions is not exact, but only modulo the value 
of variable t. Note that Proposition 1.4 implies skip;x:=2-x + y = 7 - x:=2-x + y. 

The following proposition expresses that refinement is closed under the ad- 
dition of equivalent and closed predicates to the assumptions and guarantees. 
Moreover, it captures the reflexivity and transitivity of refinement. Note that 
Preds{0) is the set of all closed (constant) predicates. 

Proposition 2. (Properties of refinement) 

1. (Closure) We have [P, P] C yy C [Q,A] iff 

[P, P U Preds{0)] C >-y C [Q, A U Preds{0)] 

where P = |P' \ P G P, P P'} and similarly for A. 

2. (Reflexivity) We have [P, P] C C [Q, 4i] iff [P, P] C [Q,A]. 
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3. (Transitivity) If/?;(Ci) C/y(C' 2 ) and 

[P,A] Ci>ViC 2 [Qi,Ai] 

and 

[Pj/Ij] C 2 '^V 2 C 3 [( 52 ,^ 2 ], 

then 

[P, PlLIPj] C*! ^ViUV 2 C '3 [<52) ^1 n Z\ 2 ]- 

□ 

Due to Proposition 2.1, equivalent and closed predicates will not be explicitly 
mentioned in the set of assumptions and guarantees of a refinement. 

The next proposition expresses both trace inclusion and execution inclusion 
as special cases of refinement. The minimal amount of environment assumptions 
Preds(0) gives rise to trace inclusion while the maximal amount of assumptions 
Preds{ Var) yields execution inclusion. All four lemmas follow directly from the 
definitions. 

Proposition 3. (Trace and execution inclusion via refinement) 

1 . If [tt, Preds(0)] C C' [Q, A] for some Q and A, then C Aj- C' . 

2. If C Aj- C', then [tt, Preds{^)] C ;^0 C [tt, Preds{%)\ . 

3. If [P, Preds{Var)] C C [Q, A] for some A, then {P} ; C Ag {P} ; C' 

and {P} C {Q} where {P} C {Q} is the standard Hoare-triple notation 
for partial correctness. 

4. If {P} ; C Af {P} ; C" then [P, Preds( Vizr)] C>-^C' [tt, Preds{%)\. □ 

Refinement is governed by the syntax-directed rules in Figures 1 and 2 on 
pages 223 and 224. Soundness of the rules is proved in [9] . 

General Refinement Methodology. Let Ci be a high-level specification of 
the implementation that is to be derived. Ci can be viewed as an abstract 
statement of the computation to be performed. More precisely, Ci defines the 
executions that all refinements, and thus also the final implementation, are al- 
lowed to exhibit. The refinement of Ci then proceeds by finding a sequence of 
programs G 2 , . . . , and Pi, Pi, Qi, and Aj such that 

[p„p,] a ^ 0 C,+i [g„A,] 

for all 1 < i < n. Intuitively, for each refinement. Pi and Pi constitute the 
minimal assumptions necessary for the refinement to hold while Qi and Ai stand 
for the maximal guarantees the new component can give to its environment. 
Assumptions and guarantees arise during the use of the refinement calculus 
presented below. With transitivity (Proposition 2.3) and the weakening rule 
WEAK the above sequence then implies 

C*! p 0 Cn 
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ASSCOM If A is an atomic statement and {P,Qj C F and (p Ac/a) ^ Q and 
AG{Q\{P A QAcfA^Q)}, then [P,P] A [Q,A], 

ATOM If Ai and A 2 are atomic statements and fv{Ai) n P = 0 and 

1. [P,r] Ai and [P,r] Az [g,A], and 

2. (3X1 ...Xn-P Ac/as) ^ (3X1 ...Xn-P Ac/aJ, then 

[P,P] Ai Az [Q,A]. 

SEQ If fv{Ci) n Pz = 0 and /?;(Cz) n K = 0, then 

[P,Pi] Ci^ViCi [Qi,Ai] [Qi,Pz] CzAvzC^ [0,^2] 

[P,PiUPz] Cl ; Cz Aviuvz C; ; Cz [g,AinAzl 

OR If fv{Ci) nPz = 0 and /u(Cz) 0 Pi = 0, then 

[P,Pi] C^'^v^C[[Q,Ai\ [P,Pz] Cz^v, [Q,Az] 

[P,PiUPz] Cl V Cz C; V [Q,AinAz] 

STAR, OMEGA 

[7,P] C>-vC' [I, A] [I,P] C>-vC' [I, A] 

[I,P] C*^v{C'T [I, A] [I,P] C^yviCT [I, A] 

PAR If fv{Ci) n Pz = 0 and /i;(Cz) O Vi = 0 and Pi C Az and Pz C Ai, then 

[Pi, Pi] Ciyv,C[ [gi,Ai] [Pz,Pz] Cz^VzO^ [Q 2 ,Az] 

[Pi a Pz, Pi U Pz] Ci jj Cz C[ jj C '2 [Qi A Qz, Ai n Az] 

NEW If P' = {P[v/x\ I P G P,u G Pom,,}, A' = {P,P[v/x\ \ P[v/x] G A,n G 
Dotrix}, then 

[P,P] CyyC [Q,A] x^V 

[P[u/x], P^j new X = V in C new x = v in C' [3x.Q, A'] 

COND If fv{Ci) n Pz = 0 and /^(Cz) 0 Pi = 0 and P ^ (P B'), 

1. [PAP, Pi] Ciyv,C[ [Q,Ai[,and 

2. [PA-nP,Pz] CzAvzOz [Q,^2], 
then 

[P,PiUPzU{P,P',^P'}] 

if P then Oi else Cz >~ViuV 2 if B' then OJ else C 2 
[Q, Ai n Az]. 

FOR If i is a constant integer variable C and C' and 
[P[k - 1/i], p] C[k/i] yv, C'[k/i] [P\k/i], Ai] , 

for all 1 < fc < n, then 

[p[^/iW:=ir^] 

for i = 1 to n do C Pui*_ v» for i = 1 to n do C' 

[f^[n/i],nr=i^.]- 



Fig. 1. Refinement rules 
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PAR-N If for all 1 < f < n 

1. [Pi,ri] Ci>-v,C'i \Qi,Ai], 8.nd 

2. Fi C and 

3. fv{Cj) C\Vi — % for all 1 < j < n with j 7 ^ i, then 



[auf,[juf] wua iiLic' [Ar=iQi>nr.i^i]- 



NEW-INTRO If r' = {P[v'/x] \ P e P,v' £ Dom^}, A' = {P, P[v'/x] \ P[v'/x] € 
A,v' G Donix}-, then 



[P,P] C^vu{.}C [Q,A] 

[P[v/x\,r'\ C 'i^v new x = v in C' [3x.Q, A'] 



WEAK If C( =r Cl, C 2 Cr C' 2 , P ^ P', Q' ^ Q, P' P, A A', and V' C V, 
then 

IP',P'] [Q',A'] 

[P,P] Ci>-vC2 [Q,zil 



Fig. 2. Refinement rules (continued) 



which yields {/\^ Pi};Ci Ag {/\. and {/\^ PJ Cn {Qn} by rule WEAK and 

Proposition 3.3. Thus, every execution a of Cn that starts in a state satisfying 
Ai Pi also is an execution of Ci and whenever a is finite, the last state satisfies 
Qn- Note that the refinement methodology assumes that all Ci have a non-empty 
set of executions. Care must thus be taken to ensure that the initial program 
and all of its refinements have a non-empty set of executions. It can be shown 
that all programs that contain the standard programming language constructs 
only, have non-empty sets of executions [9]. Consequently, whenever the most 
refined program Cn only contains the standard constructs, the entire refinement 
is non-trivial. 



4 Introducing Iteration and Parallelism 

So far, the only rule that allows the introduction of a new construct across a 
refinement is NEW-INTRO. To make our calculus more versatile we need rules 
for the introduction of loops and parallel compositions. We start with a rule for 
introducing for loops. 



FOR-INTRO. If i is a constant integer variable and 
1. for all 0 < fc < n — 1 we have 



and 



[l[k/ilPk\ C>i^C'[k/i] [l[k + l/i],Au] 
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2. I[n/i] ^ Q, 
then 



[^[0A],Ur=i^*] C*-,{Q} ^0 forz=ltondoC' [Q,nr=iA]- 

Informally, if C can be refined to C'[k/i] for each iteration k using loop invariant 
I[k/i] and assumptions and the desired postcondition Q is implied by I[n/i], 
then C* ; {Q} can be replaced by for f = 1 to n do C" under the assumptions 
/[0/f] and Ur=i-^i- ^ similar rule can be given for the introduction of while 
loops [9]. 

The introduction of parallelism is more difficult, because, due to interference 
on shared variables, the parallel execution of processes may lead to unexpected 
results. We use the fact that the behaviour of some programs is unaffected by 
parallelism. For instance, the program a;:=l •,x:=l is equivalent to the program 
a;:=l || x:=l. We introduce the notion of robustness to generalize this property. 
Informally, the semantics of an n-fold parallel composition of a robust program 
is equivalent to its n-fold sequential composition. 

Definition 6. (Robust programs) 

A program C is called robust if C* D7- C” =7- ||"C for all n > 1 where C” and 
II "C denote the n-fold sequential composition and the n-fold parallel composition 
respectively, that is, = C and = C \ C^ and ||^C = C and ||”+^C = 

C II [ 11’^ C]. □ 

Besides a;:=l, the programs x:=x + 1 and a;:=a:-|-l;a;:=a:-|-l are also robust, 
because we have chosen assignments to be atomic. The program x:=l \ x\=x+ 1, 
however, is not. Atomic statements and finite loops over them are always robust. 



Proposition 4. (Sufficient conditions for robustness) 

1. Atomic statements V\[P,Q] are robust. 

2. If C is robust, then C* and C™ for all m > 0 are robust. 

Proof: 1) is proved by induction while 2) follows from the associativity of parallel 
composition. ■ 

Robustness allows us to define a rule for the introduction of parallelism. 



PAR-INTRO. If 

1. C is robust and [tt, Preds{%)\ C and 

2. [P, Fi] C ;^0 Ci [Qi, Ai] for all I < i < n, and 

3. Fi C nj=i j/i foi' all 1 < i < n, and 

4. (VI < i < n.Qi) ^ Q, 
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then 

[P,[J^^i\ Iir=ia [Q,aA]. 

Intuitively, robustness ensures that C* can be refined into The second 

and third premise allow the refinement of H^^iC into using rule PAR-N. 

Note that FOR-INTRO and PAR-INTRO require the set of local variables V 
to be empty. While the rules could be generalized, the simpler versions suffice 
for our present purposes. 



5 Modeling Message-Passing 

In most of the literature on concurrency theory, shared-variable and message- 
passing concurrency are given sometimes very different semantic models, e.g., [5, 
6,7,4]. Since we want to be able to move freely between the two paradigms, we 
need a uniform model that captures shared-variable and message-passing con- 
currency in the same semantic framework. Consider the two standard message- 
passing primitives c?x and c!e where c is a channel. The input statement clx 
reads the next item off c and assigns it to x. If c is empty, the statement blocks 
until c is non-empty. Thus, if c remains empty forever, the statement also blocks 
forever. The output statement c!e evaluates the expression e and appends the 
resulting value at the end of c. It never blocks. The two primitives thus receive 
an asynchronous communication semantics. We fit these two constructs in our 
language by modeling a channel c as variable ranging over finite queues. More 
precisely. 



clx = await c yf () then x:=hd{c) ; c:=tl{c) end 
c!e = c := enqueue{c, e) 

where c is a variable ranging over finite queues, () denotes the empty queue, 
hd{c) and tl{c) return the head and tail of c respectively and enqueue{c,e) 
returns a queue that is like c except that the value of e is appended at the end. 
This encoding gives rise to the following rules for introducing receive and send 
statements. 

INPUT-INTRO 



[c = v::l, {c = v.d, c = l,x = u}] 

X :=v cTx 

[x = V A c = I, Preds Var\{a;, c}] 

OUTPUT-INTRO 

[x = V A c = I, {x = v,c = l,c = l::v}] 
skip c!x 

[c = l::v, PredsVar\{c}] 
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Note how the assumptions of rule INPUT-INTRO imply that the input statement 
c7x will never block forever. 

To derive a distributed program from a shared-variable program, we need to 

1 . identify the non-local information for each parallel process, 

2 . introduce channels between producers and consumers of that information 
using NEW-INTRO, and 

3. replace access to shared variables by access to the corresponding channels 
using INPUT-INTRO and OUTPUT-INTRO. 

This methodology seems well suited for parallel algorithms with a limited form 
of parallelism that allows them to be implemented without explicit synchroniza- 
tions. For instance, the Floyd- Warshall algorithm, the prefix-sum algorithm, and 
the all-pair, shortest-paths algorithm discussed below fall into this category. The 
environment of each parallel process in all of these algorithms can be shown to 
satisfy the assumptions required by rule INPUT-INTRO. 



6 Example: All-Pair Shortest-Paths 

Given an unweighted graph G = {V,E), the goal is to compute the length of 
a shortest path between any two vertices v and v' in V, dist(y,v') for short. 
The length of a path is given by the number of vertices it contains minus 1. G 
may be directed or undirected. Let n be the number of vertices in G, that is, 
n = \V\. The shortest distances are to be stored in a two-dimensional array D. 
The initial program Gi allows an arbitrary but finite number of updates to the 
array D before the final state satisfying Q = 'ix,x' G V.D[x,x'] = dist{x,x') is 
established, that is. 



Gi = 

We will begin by deriving a shared-variable implementation. Then, this solution 
is refined into a distributed implementation. The first part of the derivation is 
summarized in Figure 3 on page 228. 



Refining Ci into C 4 . Given a vertex v, the first refinement G 2 considers 
the vertices reachable from v in the order of increasing distance assuming the 
availability of the distance function dist. Formally, the refinement proceeds by 
showing 

TZi = [tt, Preds{{D})] 

{D}:[tt,tt]* )^0 11^ lljf, if u = u' then G[u, u'] :=0 else £>[u, u'] := 

nil [Va; G V.Q^, Preds{Var\{D})] 
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Cl = {D}:[tt,tt]* -,{Q} 

where Q = ^x^x' £V.D[x,x'] — dist{x,x') 
dist{x, x') = length of shortest path from x to x' . 

C 2 = 11^ 11^/ if V = v' then D[v, v'] :=0 else D[v, v'] :=nil\ 
for fc = 1 to n — 1 do 

[||^//if dist{v, v") = k then D[v, v"] :=fc]] 

od 



C 3 = new F[0..n — 1, = 0 in 

||^F[0,^]:=W; 

II ||^( if II = v' then D[v, v'] :=0 else D[v, v'] :=nil; 
for fc = 1 to n — 1 do 

F[k, u] := \J(v,v')W e ^'1 I v”] = nil}-, 

_ „ [\\J’'-''D[vy']:=k] 

od 

end 



C4 = new _F[0..n — 1, vi..Vn] = 0 in 

|irm^]:=W; 

\\X \\Z' if V = v' then D[v, v'] :=0 else D[v, v'] :=nil; 
for fc = 1 to n — 1 do 
new ti = 0 in 

new / = 0 in 
f:=F[k-l,v']-, 

E new t 2 = 0 in 

1^11^,, if D[v, v"] = nil then t 2 :=t 2 U {'r”}j ; 
ti:=tiU t2 

end 
end 

F[k,v]-.=ti 

end; 

\\\lt'’^D[v,v"]-.= k] 

od 
end 



Fig. 3. Derivation of shared-variable solution to all-pair, shortest-paths problem 
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and 



7^2 = [Vx G V.Ql,Preds{{D})] 

{Dy.[tt,ttY-,{Q} 

>“0 

for k = 1 to n — \ do 

dist{v,v") = k then D[v,v"] :=/c]] 
[Q, Preds{ Var\{D})] 



where 



= Vx' G V.dist{x,x') < fc => D[x,x'] = dist{x,x') 



for all 0 < fc < n. The proof uses ASSCOM. ATOM, Proposition 4 and PAR- 
INTRO (twice) and FOR-INTRO. Refinement between Ci and C2 then follows 
from TZi, 1^2 and 






Refinement C3 introduces the concept of a fringe. The fringe of a vertex v 
with distance fc, fringe{k,v) for short, is defined to be the set of vertices that 
are reachable from v through paths of length fc. Formally, 



fringe{k,v) = {v' \ dist{v,v') = fc}. 



If X = fringe{k, v) we say that X is the fc-fringe of v. An array of local variables 
F, where F[k,v] holds the fc-fringe of v, is introduced. In each iteration fc, the 
fc-fringe of v is obtained by considering the (fc — l)-fringes of the immediate 
neighbours of v. Formally, we have the property 



fringe{k, v) = ^ fringe{k - 1 , v') \ D[v, v"] = nil}. ( 1 ) 



Refinement between C2 and C3 is proved using the rules in Figures 1 and 2 , and 
the rules FOR-INTRO and PAR-INTRO together with Proposition 4. 
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Refinement C4 is obtained from C3 by breaking down the computation of the 
fc-fringe of v. More precisely, we use the refinement 

[Va; G V.F[k — 1, n] = fringe{k — 1, n), /^] 

F[k, v] G fringe{k - 1, v') \ D[v, v"] = nil} 

^0 

new <1 = 0 in 

new / = 0 in 
f-.= F[k~l,v']-, 

E new ^2 = 0 in 

[|l{„if D[v, v"] = nil then t 2 :=t 2 U {?;"}] ; ; 

fi:=tiUf2 
end 
end 
F[k,v\ :=ti 
end 

[F[k, ri] = fringe{k, v), A\ 



where 

F = Preds{{D[v, x],F[k — 1, x],F[k, x] | a; G R}) 

A = {F[k, v] = fringe{k, i;)} U 

Preds{{D[x, x'],F[k — 1, x] | x, x' &V}VJ {F[k, x] \ x € V A x ^ r>}). 

This refinement is derived using rules NEW-INTRO, SEQ, ATOM, and PAR- 
INTRO. Note that the correctness of this refinement crucially depends on the 
atomicity of the assignments to ti and t2- Moreover, since ti and t2 are local, 
no assumptions preventing harmful environment interference are necessary and 
reasoning is simplified considerably. Refinement between C3 and C4 follows using 
FOR, SEQ, ATOM, PAR-N, and NEW. 



Deriving a Distributed Implementation. Suppose that every vertex v only 
knows 

— its immediate neighbours, that is, E is not globally known or available, 

— its own eurrent fringe, that is, the array F[k] is not globally available 

and that all other information is considered non-local. We want to derive a 
program that is distributed in the sense that all non-local information that a 
vertex v needs is communicated to v explicitly through message passing. Let Cy 
range over each of the processes of the top-most parallel composition in the for 
loop of C 4 . Cy accesses the fringes F[k — 1 , v'] of all vertices v' that v is adjacent 
to. This information is non-local to Cy and thus needs to be communicated 
explicitly. To this end, we introduce a two dimensional array of local channels. 



A Development Methodology for Parallel and Distributed Programs 231 



Each channel c[v' , v] will be used by vertex v' to send its current fringe F[k— 1 , v'] 
to V. More precisely, the channels are subject to the following loop invariant: In 
iteration k, if {v, v') G E then c[v' , f] contains fringe{k — l, v') (and nothing else). 
The resulting program C5 is shown in Figure 4 . The Rules INPUT-INTRO and 
OUTPUT-INTRO are essential for proving refinement. 



C 5 = new c\vi..Vn,vi..Vn] = (),E[0..n — l,vi..Vn] = 0 in 
||)fE[0,u]:=W; 

||„ ||)(/ if u = w' then D\v, v'] :=0 else D[v, v'\ :=nil\ 
for A: = 1 to n — 1 do 
new = 0 in 

r new / = 0 in 

c[v',v]7f-, 

^ new t 2 = 0 in 
y [||^'/if D[v,v”] = nil then 

t2 :=t2 U {«"}]; 
ti:=tiUt2 

V end 

end 

F[k,v] :=ti 

end; 

[\CMD[v,v"]:=k] II [||f,.,„)C[u,u"]!E[fc.u"]] 

od 

end 



Fig. 4. Distributed solution to all-pair, shortest-paths problem 



Note that the number of send and receive actions in C5 depends on the 
connectivity of the graph G. Only if G is strongly connected do we get send 
actions. If G has no edges, no messages are being sent. Moreover, while the 
computation of fringe(k, v) in C4 requires direct access to the array F[k— 1 ], the 
corresponding computation in C5 does not. Consequently, the space requirements 
of C5 could be reduced by removing the array F, initializing c[v' ^v] directly 
with {f^}, wrapping the declaration of a new local variable F^^v around C„, and 
replacing F[k,v\ by „ in Gy. Due to space limitations this step is not given. 

Alternative Refinements. A different representation of Equation ( 1 ) gives 
rise to an alternative way of computing the fc-fringe of v. The fc-fringe of v is 
now obtained by considering the immediate neighbours of all vertices in the 
(k — l)-fringe of v. Formally, 

fringe{k,v) = {v" \ {v',v'') G E A D[v,v''] = nil}. 



( 2 ) 
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Suppose this property were used for an alternative refinement of C2 into C3 and 
C4 where C3 computes the fringe using (2), and C4 breaks down this computa- 
tion in the obvious fashion. We now argue that the distributed implementation 
that C4 would give rise to is less desirable than C5 given above. Program C4 
requires every vertex v to know the immediate neighbours v" of every vertex v' 
in the fringe of v. Unless v = v' , this is non-local information and thus needs 
to be communicated via channels and message-passing. Consequently, in each 
iteration, every vertex v' in the graph would have to be prepared to send a list I 
of its immediate neighbours to v. Compared to C5 a distributed implementation 
based on C4 would thus have the following main disadvantages. 

— Since vertex v' does not know the vertex v such that v' appears in the fringe 
of V, v' has to be conservative and always send I to every vertex in the graph. 
Independent of the connectivity of the graph, the total number of messages 
sent (including the initialization) would thus always be n^. 

— Since not every vertex v' appears in the fringe of another vertex v in every 
iteration, some of these messages are redundant and will never be received. 
In case of the graph with no edges, none of the messages will ever be 
received. All of them are redundant. 

We conclude that C5 is superior to the distributed implementation that C4 would 
lead to. 



7 Liveness 

Since the channels are always non-empty when any parallel computation is initia- 
ted, the above example does not require an explicit proof of deadlock freedom. 
In this section, we sketch briefly the explicit modeling and verification of liven- 
ess properties. Consider, for instance, the standard producer/consumer example 
Prod\\C ons using the shared-variable notation where 

and Cons 

The producer Prod communicates its output to the consumer via a shared varia- 
ble S ranging over sets. We want to replace the abstract statement {S', ^ 

0 ,remove{S,y)\ by an await statement await S 0 then remove{S,y). Howe- 
ver, this refinement is sound in general only if it does not introduce any infinite 
blocking at the S 0 condition. It is sufficient to show that produce{x) always 
terminates in the given context and never decreases the size of S. In terms of 
our framework this can expressed as the refinement 

[P^r] 

Var:[tt,\S\ > | S |]* produce{x) 

[tt, Preds(0)] . 



Prod = 



produce{x)\ 
insert{x, S) 



(5',2/}:[S y^ %,remove{S, y)]; 
consume{y) 
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for some P and P. To complete the proof, the environment of the producer must 
be shown to meet the assumptions P. In this case, the consumer never blocks 
forever and the above system Prod\\Cons is equivalent to Prod\\Cons' where 



Cons' 



await S' 0 then remove{S, y)\ 
consume{y) 



This shared- variable implementation can then be further refined into a distribu- 
ted solution in which the producer and consumer communicate via a common 
channel c rather than a shared variable. In [9], these ideas are generalized into 
a refinement rule for the introduction of await statements. 



8 Conclusion, Future Work, and Related Work 

A unified semantic model for fair shared-variable and message-passing concur- 
rency is given. The refinement calculus first presented in [10] is extended with 
rules for the introduction of iteration, parallelism and message-passing. We show 
how a distributed program can be derived from a shared-variable program. Al- 
ternative implementations can be explored and compared. The calculus scales to 
finer-grained concurrency with non-atomic assignments or expressions [9] . Apart 
from the all-pair, shortest-paths algorithm the methodology has also been ap- 
plied to the prefix-sum algorithm [9]. Safety and liveness properties can be ex- 
pressed conveniently in our framework. 

While our calculus allows the treatment of certain linear process topologies, 
it fails for circular process topologies required by, for instance, Dijkstra’s token 
ring algorithm. Allowing environment assumptions to contain liveness properties 
would help, but also complicate the semantics. Instead, we are currently inve- 
stigating the use of more non-compositional methods to deal with liveness [8]. 
Another focus of future work is data reification. We conjecture that our calculus 
can be extended appropriately. 

This paper extends the calculus in [10] with channels and rules for the in- 
troduction of iteration and message-passing. The ideas are presented in more 
detail in [9]. The proof systems in [11,14] both use assumption-guarantee rea- 
soning to achieve compositionality. Whereas Jones employs logical formulas to 
specify the behaviour of the program and its environment, Stirling uses sets of 
predicates like we do. The work in [15] augments Jones’ work with an explicit 
notion of refinement. Back’s refinement calculus for Action Systems [3] also mo- 
dels refinement explicitly. However, his calculus is not syntax-directed. All of the 
mentioned approaches differ from ours at least in that they lack uniform support 
for shared variables and message passing. 
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Abstract. In this paper, we investigate how to represent the behaviour 
of B abstract systems by Hnite labelled transition systems (LTS). We 
choose to decompose the state of an abstract system in several disjunctive 
predicates. These predicates provide the basis for defining a set of states 
which are the nodes of the LTS, while the events are the transitions. We 
have carried out a connection between the B environment (Atelier B) 
and the Gassar/Aldebaran Development Package (CADP) which is able 
to deal with LTS. We illustrate the method by developing the SCSI-2 
(Small Computer Systems Interface) input-output system. Finally, we 
discuss about the outcomes of this method and about its applicability. 



1 Introduction 

Abstract systems were introduced in 1996 by J.-R. Abrial [2] in the framework 
of the B method. This proposal was very much influenced by the work on Ac- 
tion Systems [4]. Abstract systems have a state like abstract machines, but the 
operations are replaced by events. Events are not invoked as the operations, but 
they can be enabled if their guard is true. Then, one of the enabled events may 
be fired and the state of the system is changed according to the event action. 
Abstract systems can be refined and dynamic constraints can be specified to 
express various properties not expressible as invariant [3]. 

In this paper, we are interested in representing the behaviour of abstract 
systems and to extract information from this representation. The aim of the 
study is to investigate how the behaviours can be interpreted by finite labelled 
transition systems (LTS). Moreover, we develop the first specification steps of a 
simplified version of the SCSI-2 [17] (Small Computer Systems Interface) input- 
output system. This system was designed to manage the command and data flow 
between a controller and peripherals through a shared bus. This case study illu- 
strates several points of the approach. Our method, already proposed by other 
people [12], consists in the decomposition of the state of abstract systems in 
several cases, by the way of disjunctive predicates. These predicates provide the 
basis for defining the set of states that are the nodes of the LTS, while the events 

* This work was partly supported by INRIA Rhone-Alpes, through the action VER- 
DON (VERification et test de systemes reactifs critiques comportant des DONnees), 
URL: http: //www. inrialpes . fr/vasy/verdon/. 

W. Grieskamp, T. Santen, and B. Stoddart (Eds.): IFM 2000, LNCS 1945, pp. 235—254, 2000. 

(c) Springer- Verlag Berlin Heidelberg 2000 
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are the transitions. We show that this representation can be used to prove some 
properties by model-checking or by calculation on the graph. However the bott- 
leneck of the approach is the computation of the transitions which “abstract” the 
behaviour of the system. This computation is achieved by proving formulas. Be- 
cause this process is not decidable, the computation requires human interaction 
or, easier, the undecidability is encompassed in the abstraction. That means, 
for instance, that if a transition is not automatically proved (nor disproved), 
then it is assumed to hold; so the construction of the LTS can be fully auto- 
matic. Then the resulting LTS is processed by an environment called CADP^. 
This environment ( Caesar/ Aldebaran Development Package) [10] is a toolbox for 
protocol engineering. It offers a wide functionality, from interactive simulation 
to the most recent formal verification techniques based on model-checkers for 
various temporal logics and /r-calculus. 

Section 2 gives useful definitions and introduces the SCSI-2 example. Sec- 
tion 3 presents various ways to build finite LTS from abstract systems, then it 
defines our method of decomposition. Section 4 develops the example and pro- 
vides insights about the applications of the method. Finally, Section 5 details 
functionalities of CADP and the algorithm to build effectively states and tran- 
sitions as input for the toolbox. In the conclusion, we indicate what could be 
some other research directions inside this technology. 



2 Abstract Systems and Labelled Transition Systems 

2.1 Abstract Systems in B 

The internal state of abstract systems is composed of a list of variables X = 
{xi,X 2 , . . . ,Xfc). These variables take their values in a set D = Di x ... x Dj^ 
and must satisfy an invariant I. The semantic interpretation of a state over X in 
defined by a mapping a that associates with each variable Xi £ X & value Vi G Di. 
We denote by a{xi) the current value of Xi in the state a. We notice that a can 
be considered as a generalized substitution (B-Book [I] , page 265) and it will be 
used as such in this paper. The state space of an abstract system is then the set of 
values of the variables which satisfy the invariant. When a machine or a system 
is not deterministic, it can be useful to consider that a variable is associated 
with a set of values. In such a more general framework, the interpretation of 
the variables is done in a set V of the form: V = P(Di) x . . . x P(Dfe). There 
is an obvious correspondence between the interpretation of variables in values 
sets, and sets of states in the first interpretation. Alternatively and equivalently, 
states may be characterized by predicates. All of these interpretations will be 
used in this paper and made explicit if necessary, according to the contexts. 

The generalized substitution U of the initialization determines a subset of 
values which constitute the initial states of the abstract system. The dynamic 
part of an abstract system consists in a list of events, that is to say, declarations 



^ URL: http://www.inrialpes.fr/vasy/cadp/. 
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of the form: = E” , where £ is the name of the event and E is the definition 

(the body). In this paper, the event bodies have the two following forms: 

SELECT P THEN A END 
ANY Z WHERE P THEN A END 

In the events above, we say that the guard (denoted by grd) is the feasibility 
condition [1] of the generalized substitution of the event body and the aetion is 
the A part. So, we have: 

grd (select P then A end) = P a grd(^) 

grd (any 2 ; WHERE P THEN A end) = 3z ■ {P A grd (A)) 

In many cases, the action A is an always feasible substitution (simple substitu- 
tion, etc.). Then the guard of the events reduces to P for the first form or 3z- P 
for the second one. In this paper, we assume that the termination condition of 
the events is true. If the list of events of a system is £ 1 , £ 2 , • ■ • , £m, then a system 
is deadlock free if and only if (iff) the disjunction of the guards is true when the 
invariant holds [3]: I ^ \/^-^grd{Ei) . An event £i is enabled in a state a iff 
[cr]grd(ifi) holds. For deadlock free abstract systems, in any valid state, there 
are always enabled events. Finally, we use the conjugate weakest precondition: 

{S)P = 

This construction [6] computes the weakest precondition which asserts that it is 
possible for S to establish P. 

2.2 Example of an Abstract System 

We want to specify some characteristics of an input-output system based on 
the bus SCSI-2. The aim is to control the requests of the accesses to the bus. 
Here, we consider that the peripherals are only disks. The controller and the 
disks share the bus in which messages are transmitted from the controller to 
the disks or from the disks to the controller. At a high level of the specification, 
the SCSI-2 system is seen as centralized. The bus and the arbitration algorithm 
to take control of the bus, will be introduced further by refining the system. 
Each disk gets a buffer (a queue) where commands are pushed on until they 
are processed. This first specification says only that the controller can send a 
command to a certain disk jj iff the buffer of this disk is not full. On the other 
side, a disk can consume a request (and can send the result to the controller), iff 
it actually gets something to do, that is to say, if its buffer is not empty. For the 
sake of simplicity, the size of the buffers is only represented, not their content. 
This is expressed by two events: 

ctr^cmd the controller sends a command to a disk jj 
dsk-rec the disk jj consumes a request from its buffer 

The useful declarations are: 
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DSK the set of the disks 

maxi the maximum length of the buffers 

SIZE the range of the buffer size (from 0 to maxi) 

The abstract system is defined as shown in Fig. 1. 



SYSTEM SCSI-2 




VARIABLES buf 




INVARIANT 




bufG DSK ^ SIZE 




INITIALISATION 


/* at the beginning, the buffers are empty * / 


buf— DSKx {0} 




EVENTS 




ctrjcmd = 


j* a command is sent to the disk jj * j 


ANY jj WHERE 




j] G DSK A 


buf{jj) < maxi 


THEN 




bufijj) ■- bufijj) + 1 


END; 




dskjrec = 


/* the disk jj consumes a request * / 


ANY jj WHERE 




JJ G DSK A 


o 

A 

> 

.o 


THEN 




bufijj) ■- buf{jj) - 1 


END 




END 





Fig. 1. Simple specification of the SCSI-2 input-output system. 



2.3 Labelled Transition Systems 

A labelled transition system T is defined by (iV, M, L, TV) where: 

— is a set of nodes or states, 

— M is the set of initial states and M C N, 

— L is a set of labels, 

— TZ G ¥{N X L X N) is the transition relation. 

A transition {qj, I, qk) G TZis also denoted by qj — ^ qk- Any labelled transition 
relation TZ can be reduced to a binary relation on states (by forgetting the labels) 
R G P(iV X N), by: 

R = { {q,q') \ 31 ■ {I G L A q — ^ q' G TZ) } 

The transitive closure is denoted by i?+, the reflexive and transitive closure by 
R* and the inverse by R~^. A state q G N is reachable iff g € R*\M], that is to 
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say, q belongs to the image^ of the initial states by the reflexive and transitive 
closure of i?. If i? C 7Vi x N 2 then we denote by pre[R] G IP(1V2) — f P(-^i) the 
“predecessor” function on sets of states and by post[R\ € P(A^i) — >• P(iV 2 ) the 
“successor” function. Let Q be a subset of iV, then Q is the complement of Q 
with respect to N . The following definitions are usual on binary relations [18, 
15], where R C Ni x N 2 , Qi Q Ni and Q 2 C N 2 : 

pre[R]{Q 2 ) = { q \ q G Ni A 3q' ■ {q' G Q 2 A {q,q') G R) } 
post[R]{Qi) = { q' \ q' G N 2 A 3q- {qGQi A {q,q') G R) } 
j^[R]{Q 2 ) = pre[R]{Q 2 ) 
post[R]{Qi) = post[R]{Qi) 

If R is total, then pre[i?j C pre[R] and if i? is a function, then p?e[i?] = pre[R]. 
For labelled transition systems, the labels can be considered as references to 
the relations they label. So, the following definitions will be used, where TZ C 
(TV X L X TV) and Q C N\ 

pre[l]{Q) = {q \ qGN A 3q' -{q^ gQ A {q ^ q') G TZ) } 
post[l]{Q) = { q' \ q' G N A 3q- {q G Q A {q -4 q') G TZ) } 

3 Principles for the Construction of Finite LTS 

In this section, we study several ways to build finite labelled transition systems 
from B abstract systems. To illustrate the various cases, the example of the 
specification of SCSI-2 (Fig. 1) will be taken. 



3.1 Enumeration of the States 

The simplest way to define a labelled transition system from a B abstract system 
is to enumerate the states and the transitions. Given an abstract system S with 
list of variables X = (xi, . . . ,Xk), invariant /, initialisation U, list of events 
{£i = Ei) for i G l..m, then the initial states are the assignments cto: 

(To = { Xj I— >■ Vj I {U){Xj = Vj) } \/j G l..fc 

For each state ap which satisfy the invariant I and each event f,, such that this 
event is enabled in the state cTp, the successors of (Jp by the transition labelled by 
£i are the states the values of which are possibly obtained after the generalized 
substitution Ep 

(Tp+i = { Xj 1-^ v'j I [ap] {{Ei) {xj = Vj))} Vj e l..k 

From the definitions of the B-Book [1] (page 296), that means that, if {xj 1 — >■ 
Vj) G ap then 

{vj,v'j) Gre\^j{E,) 

^ In the paper, we use systematically the B set notations. 
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where re\xj{Ei) is the binary relation which relates the values of Xj before and 
after the substitution Ei. Because of our assumption about termination, the link 
between the B events Ei = Ei and the transitions of the associated LTS is: 

post[£i] = re\{Ei) 

from which, we deduce: pre[£i] = re\{Ei)~^ and pfe[£i] = str{Ei). Usually, we 
will be interested in the reachable states; these states can be built inductively 
from the intial states. As an application, the LTS obtained from the example of 
Fig. 1 when maxi = 2 and DSK = {dl, d2} is given in Fig. 2. It exactly contains 
3^ = 9 reachable states. 




Fig. 2. LTS of the enumerated states of the simple SCSI-2. 



3.2 Symbolic Evaluation and Set Constraints 

This approach was taken in [16] by using a formalism of constraint logic pro- 
gramming. The idea is to deal with a symbolic representation of the states or 
more precisely, with a representation of states by a mapping between variables 
and set constraints. The language of set constraints can be supported by logical 
solvers, augmented by procedures for solving satisfaction of set constraints [13, 
14]. 

Set constraints are built upon usual set connectors, as G,^, =,y^, logical 
connectors A,V,V, 3 and the cardinality constraint. They are extended to car- 
tesian product to encompass operations of relations and functions. All the ope- 
rators on sets must be interpreted as operators on set constraints. This algebra 
is not developed here. In the same way, integer values must be represented as 
constraints (not implemented in [16]). The computation of reachable states relies 
upon several operations. Let C\ and C 2 be set constraints: 

— Cl 0 C 2 is the union of both constraints; 
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— Cl C C 2 is the inclusion of set constraints. This inclusion means that the 
state represented by the constraints C 2 satisfies the constraints expressed by 
Cl- This can be used to prove that a state satisfies the invariant; 

— reduction (red) of constraints into a normal form with disjunctions (V) of 
set of constraints; 

— Cl — {a;} suppression of x in the set of constraints Ci; 

For building LTS, there must be a procedure for the comparison of sets of set 
constraints, and for deciding if set constraints are satisfiable. Finally, the ge- 
neralized substitutions must be interpreted as operations on constraints. If the 
substitution S is enabled in a state Cp, then the operation propagate(Cp, S) 
compute a new set of constraints which is the propagation of Cp through S. For 
example, we have for the simple substitution cases: 



s 


propagate(Cp, S) 


Condition 


X := V 

skip 

P 1 S 
P=^ S 
S 1 T 


[x := x'] (red(Cp ® x' = v) — {a:}) 

Cp 

propagate(Cp 0 P, S) 
propagate(Cp, S) 

propagate(Cp, S) \J propagate(Cp, T) 


Cp(B P satisfiable 
PCCp 



One can notice that, if the state space of the actual system is finite, then, it is 
possible to generate enumerated states from constrained states (by enumeration). 
Because B is strongly based on set theory, this method allows the generation of 
transition systems up to set properties (commutativity and associativity of the 
choice of elements in the B sets). In our example, if we choose as above the 
cardinal of DSK to be 2, then the generation of the whole LTS is reduced by 
the method of set constraints to only 6 states. This is represented in Fig. 3. 
In the states, the variables do not identify specific elements. They contain the 
information about the elements, independently of their name. Indeed, all the 
states contain the constraint: jjl G {dl,d2} A jj2 G {dl,d2} A jjl yf jj2. For 
instance, in the second state of the figure below, which represents two states of 
the enumerated graph, if the event ctr_cmd is fired, then the interpretation of 
the “any” substitution chooses a new element as either the one already chosen 
ijl or the other one H2 different from ijl. After that, in any cases, from both 
states, a new ctr-cmd event leads to only one event where a buffer is full (2 
messages) and the other contains one element. 



3.3 Abstract Interpretation 

Abstract interpretation [7] is a very general technique which relies upon evalua- 
tion of syntactic descriptions (programs, specifications, etc.) into non-standard 
domains. These domains are usually simpler than the original ones. The interest 
of abstract interpretation is that it is possible to check automatically, on the 
abstract domain, properties that hold on the effective domain but which are 
not decidable on it. Obviously, the abstraction must be chosen appropriately to 
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buf(jjl) = 2 
buf(jj2) = 0 




buf(jjl) = 2 
buf(jj2) = 2 



Fig. 3. LTS of the constraint states of the simple SCSI-2. 



preserve the desired properties. Moreover, the result is the most often an ap- 
proximation of the effective properties, not an exact calculus. Nevertheless, the 
method is more and more used in various areas (imperative programming, logic 
programming, concurrent and distributed processing, rewriting systems, etc.). 
In the domain of transition systems, a lot of work has been done to deal with 
infinite systems and to extend capabilities of model-checking. One can cite [8,9, 
11,5] among others. A systematic study of the properties preserved by abstrac- 
tion has been done in [15]. Here we want to apply the mechanisms presented 
in [12] to B abstract systems. With respect to this work, we intend to use the 
B toolbox to validate the conditions that define the transitions rather than the 
Pvs theorem prover. 

An abstract LTS is similar to a concrete LTS, except that the set of nodes is 
a powerset of ordinary nodes. So, the nodes are structured as lattice, that is to 
say, are closed by the operations of union U and intersection n. The top element 
(T) represents all the nodes and the bottom element (T) represents the state of 
an empty set of nodes. Any LTS can be “lifted” into a powerset LTS, by taking 
the union of states and the unions on transitions. This powerset is ordered by 
the inclusion relation deduced from the lattice structure. 

The abstraction relation between concrete and abstract labelled transition 
systems is characterized by a pair of monotonic functions (0,7) from P(7V) to 
also called Galois connections: 

Definition 1 (Galois connections of LTS). LetT = {N, M, L,TZ) be a con- 
erete LTS (Section 2.3) and = {N^,M^,L,TZ^) be an abstract LTS, then 
(0,7) is a Galois connection between T' and'T^ iff the following conditions hold: 

1. aG P(A^) ¥{N^) and 7 e P(iV^) P(A^) 

2. a o 7 C O'^’d idp(Ar)C7oa 

3. M C 7(M^) 

4- yi G L,Mq^ G P(7V"^), post [Z] (7(9"^)) C ^{post[l]{q^)) 

The first two conditions are very general in the framework of abstraction [15]. 
The last two ones are specific to LTS. They express that for each concrete beha- 
viour, there exists at least one abstract behaviour described by the abstract LTS. 
So, the abstract behaviours contain all the concrete behaviours. The mappings 
a and 7 can be deduced from each other by: 
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Proposition 1. For any connection (0,7) from F{N) to ¥{N^), we have: 

1. 7 = Ay • U{ 2- € ¥{N) I a(Z) CY } 

2. a = XZ-f]{Y G P(iV^) I Z C 7(y) } 

As previously, we first illustrate the approach on the example of Fig. 1. In 
this abstraction^ of SCSI-2 (called SCSI-2^^), we consider a state mm which is 
the number of messages which are in the disk buffers. So, the variable of this 
abstract system is semantically defined as: 

mm = Sjj- {jj G DSK \ buf{jj)) 

The next step is to compute an abstract LTS from SCSI- 2^^ where the state is 
mm and to compare it with the LTS presented in section 3.1. In this new LTS, 
the union of states (in the lattice of the states) could be considered as other 
states. They are useless here, so they are not drawn to simplify the figure. 



A 

mm = 0- 



ctr cmd 



dsk rec 



mm = 1 



ctr cmd 



dsk rec 



C 

mm = 2 



ctr cmd 



dsk rec 



D 

mm = 3 



ctr cmd 



dsk rec 



■(E 

mm = 4 



Fig. 4. LTS of the first abstract SCSI-2. 



The correspondence between the enumerated LTS in Fig. 2 and the abstract one 
in Fig. 4 can be defined completely on the states, through the abstraction and 
concretization functions. The abstraction conditions hold trivially with these 
functions. Because the states are finite, this can be listed as in the following 
table : 



G ¥{N) 


a{u) G P(A^) 


p G P(1V'^) 


7(h) e ¥{N) 


0 


0 


0 


0 


{1} 






{1} 


{2} 


{B} 


{B} 


{2,3} 




{A,B} 


{A,B} 


{1,2,3} 



3.4 Yet Another Abstract Interpretation 

Another simple abstraction of SCSI-2, called SCSI-2^^ is defined by a boolean 
variable: 

empty = bool(Vjj • {jj G DSK buf{jj) = 0)) 

In that case, the abstract LTS contains two states and the transitions given in 
Fig. 5. 

® It is worth noticing the terminology problem. Here we want to take an abstract 
interpretation of an abstract system. We hope that the context allows the reader to 
understand what abstraction is meant. 
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ctr_cmd 



dsk_rec 



Fig. 5. LTS of the second abstract SCSI-2. 



If we consider the definition of the abstract variables with respect to the con- 
crete ones, it determines an obvious relation. For example, we have the relations: 

Pi = { buf,mm I mm = Ejj- {jj £ DSK \ buf{jj)) } 

P2 = { buf, empty \ empty = bool(Vjj- {jj £ DSK ^ buf{jj) = 0)) } 

So, given such a relation p C N x it is possible to build Galois connections, 
as expressed in Proposition 2 [15]. 

Proposition 2. Let p be a relation on N x N^, then the pair (post[p\^ pre[p\) 
is a connection from F{N) to P(iV"^). 



3.5 A Simple Abstraction Scheme: Disjunctive Decomposition 

In B, the state X is specified by a predicate (the invariant) I. The principle 
of the abstraction that we call disjunctive decomposition is to find n predicates 
4>i, ... ,4>n such that: 

n 

/ \J 4>j 

i=i 

In the following, we consider that each predicate I A (j)j is identified by a state qj. 
To consider the disjunctive decomposition as an abstraction, we have to define 
the abstraction framework, as sketched now. 

The states can be combined by logical connectors, thus providing the lattice 
structure of the abstract system space. The nodes of this state space are denoted 
by boolean expressions of the form /3(gi, ..., q„). The concretization function is 
then defined by: 



j{/3{qi,...,qn)) = { X \ [qj := (j)j]{(3{qi, ..., q^)) } 

More specifically, we have 'y{qj) = { x \ I A (fj }. Following Proposition 1, the 
associated abstraction function could be: 



«(z) = A( P{qi,...,q„) I Z C 7(/3(gi,...,g„)) } 
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that is to say, if Z is characterized by the predicate (j): 

a{4>) = /\{ I 4>^ fe := } 



Rather than this complex definition, following [12], we use the approximation: 

n 

«'(</>) = f\{qj\ 

i=i 



The pair (Q;^ 7 ) is a Galois connection too. Moreover, the computation of the 
abstract transition relations can be restricted to the calculus on the states 
/ A = Qj. 

Transitions are associated to the events of the B system. One says that the 
event Ei is an abstract transition between the states and if the guard is 
true in the concretization of qj and if it is possible to reach the concretization 
of qk- 



Si 

qj )■ qk 



<t7 



( I A (j)j ^ grd{Ei) 
\l A 4>j ^ {Ei) 4>k 



The initial abstract state is the set of states which are possibly true after the 
initialization, that is: 



g„ € ^ {U) (/ A cj)^) 



The abstraction SCSI- 2^^ is a particular case of disjunctive decomposition with: 



A.1 Vjj- (jj £ DSK => buf{jj) = 0) 
A2 3jj ■ {jj & DSK A buf{jj)^0) 



The condition buf G DSK — >■ SIZE A1 V A2 holds. Moreover, this decom- 
position is a partition because: A1 A A2 FALSE. 



4 Construction of Abstract LTS and Applications 

4.1 The SCSI-2 Example Continued 

We are now interested in refinements of the SCSI-2 input-output system. The 
next refinement is to introduce a bus. This bus is either empty or it contains 
only one command. This command is a command sent from the controller to a 
disk uu or it is the end of processing a command by the disk vv. So, the set of 
information transmitted by the bus is: 

0 the bus is empty 

{ CMD I— >■ itw} a command is sent to the disk uu 

{REC I— >• uu} end of command processing from the disk uu 

The command set on the bus consists of the enumerated set: ACT = {CMD, 
REC}. The variables are: 
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the bus 

information on the disks known by the controller 
information known by the disks 



bus & ACT ^ DSK 
c2_dsk G DSK ->■ SIZE 
d2Jouf G DSK SIZE 

The gluing invariant means that the informations on both sides of the bus are 
equal if the bus is empty. Otherwise, there is a difference because of the delay 
between the sending and the reception of a message, via the bus. The expression 
f <A- {x 1-^ v} means that the function / is modified at the point x by the value 
V (function overriding). 

{bus = 0 {c2.dsk = buf A d2-buf= buf}) A 
Vuu • {uu G DSK A bus = { CMD i— >■ uu} => 

{c2_dsk = buf A {d2_buf {uu i— >■ d2_huf{uu) + 1}) = hufj) A 
Vuu • {vv G DSK A bus = [REG i-A vv} => 

{{c2_dsk <G- [vv i-A c2_dsk{vv) — 1}) = buf A d2J)uf= buf)) 

In this refinement, we consider four events (see Fig. 6): 

ctr_cmd the controller sends a command through the bus 
dsk_cmd a disk receives a command from the bus 
dskjrec a disk sends the result of a command through the bus 
ctrjrec the controller receives the result of a command from the bus 



As an application of the method of construction of a labelled transition sy- 
stem, we apply the method on the set of states: 

B1 bus = 0 

B2 3jj ■ {j] G DSK A 6ms = { CMD ^ jj }) 

B3 3jj ■ {jj G DSK A bus = {REC jj}) 

The associated LTS contains three states. The events which are enabled in each 
state are computed from the conditions on the guards. For example for Bl, the 
following proof obligations are generated: 



1. / A bus = 0 

2. / A bus = 0 

3. / A bus = 0 

4. / A bus = 0 



3i/’ {jj G DSK A c2_dsk{jj) < maxi A bus = 0) 

- {jj G DSK A bus = {CMD >->• jj}) 

- {jj G DSK A d2-buf{jj) > 0 A bus = 0) 

{jJ G DSK A bus = {REC ^ jj}) 



From these conditions, 1 and 3 are true. But 2 and 4 are not proved. That does 
not mean that the guard is effectively false. For that we have to prove: 

2' . I A bus = 0 => y jj - {jj G DSK bus yf {CMD jj}) 

4'. I A bus = 0 => y jj - {jj G DSK bus yf {REC i-A- jj}) 

The successors of the state Bl by the event ctr-cmd can be computed from the 
conditions below, where Ectr_cmd is put for the generalized substitution “any 
jj WHERE jj G DSK A c2_dsk{jj) < maxi A bus = 0 then bus := {CMD 
jj} II c2_dsk{jj) := c2_dsk{jj) + 1 end”: 
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EVENTS 

ctr^cmd = /* CTR seirds a command through the bus * / 

ANY jj WHERE 

jj € DSK A c2_dsk{jj) < maxi A bus = 0 

THEN 

bus := {CMD I— >■ jj} II 
c2_dsk{jj) := c2_dsk{jj) + 1 
END; 

dskjcmd = /* jj receives a command from the bus * / 

ANY jj WHERE 

jj G DSK A bus = {CMD i-A jj] 

THEN 

bus 0 II 

d2-buf(jj) ■- d2^buf{jj) + 1 
END; 

dskurec = /* jj sends the result of a command */ 

ANY jj WHERE 

jj G DSK A d2-buf(jj) > 0 A bus = 0 

THEN 

bus ■- {REC^jj} II 
d2.buf{jj) ■- d2.buf{jj) - 1 
END; 

ctrjrec = /* CTR receives a result from the bus */ 

ANY jj WHERE 

Jj G DSK A bus = [REC ^ jj] 

THEN 

bus := 0 II 

c2-dsk{jj) := c2Msk{jj) — 1 
END 

END 



Fig. 6. First refinement of the SCSI-2 system. 



I A huS — 0 ( £^cir_cm(i ) (&W5 — 0) 

I /\ bus = % ^ {Ectr^cmd ) (3jj • {jj G DSK A 6ms = {CMD i-T jj})) 

I A bus = 0 ^ { Ectr_cmd ) • {jj G DS'if A 6us = {REC i-T jj })) 

The second formula holds, so one concludes that the transition: B1 B2 is 

possible in the abstract LTS. Here again, if the formula is not proved, one must 
try to prove the negation to be sure that the transition is not possible at all. 
From the complete calculus, the transition graph looks like the one in Fig. 7. 



4.2 Disjunctive Decomposition and B Refinement 

In a system refinement, as for a machine refinement, if the abstract system 
invariant is denoted by /, then the refined system invariant is J where the 
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ctr cmd 




Fig. 7 . Bus automaton of the SCSI-2 refinement. 



relation between the concrete state space on y and the abstract state space on 
X is given by: / A J. Obviously, the new state space is the set of y that satisfy 
3x ■ {I A J). 

When the abstract state has been decomposed into a set of disjunctive pre- 
dicates Vj=i it is interesting to see if the refined state can be decomposed 
into images of the abstract system. The principle is easy; we have: 

n n 

/ A T => / A \J (j)j f\ J ^ \J {I A (j)j A J) 
i=i i=i 

From a theoretical point of view, the refined state is decomposed into n sub- 
spaces defined by: 

3x ■ {I A (j)j A J) 

If the variables x can be eliminated from this formula, then the expression pro- 
vides a way to decompose the refined system. 

Let us take the abstract SCSI-2 system with the second abstraction defined 
in Section 3.4. The calculus of A1 refined by the refinement above produces the 
case AT (empty = true): 

(bus = 0 (c2_dsk = d2-buf A Vjj • (jj G DSK => c2_dsk(jj) = 0))) A 
Wuu ■ (uu € DSK bus ^ {CMD i— uu}) A 
yvv ■ (vv G DSK A bus = {REC >->■ vv} => 

(Vjj • (jj G DSK d2.buf(jj) = 0 A (jj ^ vv ^ c2_dsk(jj) = 0)) 

A c2_dsk(vv) = 1)) 

The state A2' is the complement of AT. The graph obtained by this abstraction 
is displayed in Fig. 8. 

Another case of relationship between a refined and an abstract system is 
when the latter is decomposed into several states: cj>i,(j> 2 ,- ■ - 4>p- If th® abstract 
states are denoted by qj, j = l..n and the refined ones by r/, I = l..p, then the 
two LTS are themselves related by the state relation: 



{ qj,ri \ 3x ■ (I A J A cji ^ cjj } 



4.3 Properties of Abstract Transition Systems 

In this section, we consider the properties which can be proved by using the 
abstraction scheme defined by a disjunction of predicates and the representation 
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Fig. 8. LTS of the refinement of Fig. 5. 



of an abstract system 5 by a finite LTS T. From the definition of the initial 
states and the condition that all the abstract values are represented, then the 
concretization of the initial states of T is included into the initial states of S. 
Then for any change of state aj to ak obtained by the event (where aj and 

s 

(Tfe satisfy the invariant /), there exists a transition qji — ^ q^i in 'T. So, the first 
result is [15]: 

Proposition 3 (Invariant properties). Any property which is true on the 
reachable states of an LTS T built from an abstract system S by a disjunctive 
decomposition is an invariant property in S. 

An improvement of the proposition above to prove invariant properties by 
model-checking on abstractions of the transition systems is to compute back- 
ward by approximation all the predecessors of a state which satisfy the desired 
property [5]. This technique builds a finite LTS which proves that the property 
holds in the actual system if the initial state(s) is (are) in the LTS. Obviously, the 
technique may not succeed, if the property does not hold, or if it is not inductive 
(so there is no possible finite decomposition) . We have not yet experimented this 
method with the tools we develop around the B formalism. 

In the refinement of abstract systems, new events can be introduced. These 
new events must refine the substitution skip. Moreover, to satisfy fairness con- 
ditions, the new events must not take control for ever, thus not preventing the 
“old” events to occur. Otherwise, the behaviour of the refined system should not 
be the same as the behaviour of the abstract system. In Abrial and Mussat’s 
paper [3], it is suggested that this proof can be done by the way of variant ex- 
pressions which give a termination condition for the cycle of new events. Here 
we indicate another way connected to the construction of LTS. 

Proposition 4 (Fairness of new events). In a LTS built from a refined sy- 
stem by a disjunctive decomposition, if there is no cycle of new events, then the 
refined system is fair, with respect to the old events. 

The proof is obvious because if there is a cycle of the new events in the effec- 
tive behaviour of the refined system, then there is also a cycle in the associated 
LTS, whatever the abstraction is. 
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In the example of the refined system of Fig. 8, the new events appear in 
cycles. So, we cannot conclude that the refinement is fair by this abstraction. 

4.4 Development of the SCSI-2 System 

The next development of the SCSI-2 system consists in finding an arbitration 
protocol to take control of the bus. In a simplified view of the SCSI-2 system, we 
can say that each peripheral gets a number which is its priority. The controller 
gets the highest priority. When the controller or a peripheral wants to transmit 
a message, then it asks for an access. All the peripherals and eventually the 
controller which ask for the access to the bus are competing all together. The 
device with the highest priority wins the control and can use the bus. To specify 
this arbitration protocol, we use a set of natural numbers identifying the devices 
DEV. In the minimal configuration, this is the interval 0..7, where 7 is the number 



of the controller denoted CTR. So, DSK\J{CTR} = DEV and DSKC\{ CTR} = 0. 
The set of peripherals which want to access the bus, is defined by: 



When the set wire is not empty, the winner of the arbitration is the number kk 
which satisfies: 



We must keep the information that a controller decides to be engaged with a 
disk. For that, the new variable dskjreq G DEV contains the value of the disk 
number jj if the controller is engaged with jj, otherwise, it contains the value of 
the controller. This is specified by the predicate: 



The new events are those where a peripheral or the controller asks for the access 
to the bus. They are: 



The refinement of the events is given in Fig. 9. 

We apply the method of disjunctive decomposition of the state of this refined 
system by considering the following cases: 



wire G F{DEV) 



winner(kk) 4^ bus = 0 A kk = max(wire) 



ctr _engaged dskjreq € DSK 



ctrMcc the controller asks for the access to the bus 
dskMcc a disk asks for the access to the bus 



Bl. bus = 0 

B2. 3jj ■ {jj G DSK A bus = {CMD >->• jj}) 

B3. 3jj- {jj G DSK A bus = {REC^ jj}) 

Cl. wire = 0 
C2. CTR G wire 

C3. 3jj-{jjGDSK A jj = max.{wire)) 

Dl. dsk.req = CTR A Vjj • {jj G DSK => jj ^ wire) 
D2. dsk.req = CTR A 3jj- {jj G DSK A jj G wire) 
D3. 3jj ■ {jj G DSK A dskjreq = jj) 



as previously for 
the bus automaton 



that is: winner{CTR) 
that is: winner{jj) 
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EVENTS 

ctr^acc = ANY jj WHERE 

jj € DSK A c2_dsk{jj) < maxi A -< ctr _engaged 

THEN 

wire ■.= wire U {CTK\ || dskjreq jj 

END; 

ctr_cmd = select 

ctr^engaged A winner{CTR) 

THEN 

bus := {CMD I— dskjreq} || c2_dsk{dsk_req) ~ c2_dsk{dsk_req) + 1 
dskjreq := CTR || wire := wire — {CTR} 

END; 

ctrjrec = ANY jj where 

]] £ DSK A bus = {REC i-A jj} 

THEN 

bus := 0 II c2_dsk{jj) := c2_dsk{jj) — 1 
END; 

dsk.acc = ANY jj WHERE 

jj £ DSK A bus = {CMD i— >■ jj} A jj ^ wire 

THEN 

wire := wire U {jj} 

END; 

dsk-cmd = ANY jj where 

jj £ DSK A bus = {CMD i-A jj} A jj £ wire 

THEN 

bus := 0 II d2.buf{jj) := d2.buf{jj) + 1 

END; 

dskjrec = ANY jj where 

jj £ DSK A d2Jmf{jj) > 0 A winner{jj) 

THEN 

bus := {REC ^ j]} II d2_buf ijj) ;= d2Tuf{jj) ~ 1; 

IF d2J>uf(Jj) = 0 THEN 
wire := wire — {jj} 

END 

END 

END 



Fig. 9. Second refinement of the SCSI-2 system. 



Conditions C describe the winning conditions by the examination of the content 
of wire. Conditions D indicate when the controller is engaged with a disk or not. 
Because the predicates range over various variables, we consider the decomposi- 
tion obtained by monomials on the three groups of predicates. That means we 
have the states B1 A Cl A Dl, B2 A Cl A Dl, . . . , B3 A C3 A D3. Among these 
27 states, only 10 are reachable from the initialization, which is characterized by 
B1 A Cl A Dl. The graph of the LTS is shown in Fig. 10. 
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Fig. 10. LTS of the refinement of Fig. 9. 



On this graph, the relation with the LTS displayed at Fig. 7, corresponds to 
the homomorphic grouping B1 = {1,9,12}, B2 = {2,6,7,10} and B3 = {5,11,14}. 
From a simple examination of the transitions, it is clear that the new events of 
the refinement {ctr^acc and dsk-acc) cannot take the control for ever. 



5 The CADP Tool 

CADP [10] is a toolbox for protocol engineering. It offers many functionalities, 
from interactive simulation to the most recent formal verification techniques. 
It is dedicated to the efficient compilation, simulation, formal verification, and 
testing of descriptions written in the ISO language LOTOS. Besides the LO- 
TOS language, the toolbox accepts descriptions as finite state automata, and 
networks of communicating finite state automata. By this way, we can transfer 
an LTS computed by analysis of an abstract system into the CADP environ- 
ment. Among the other functionalities of CADP, there are two different tools for 
computing bisimulations, that achieve minimizations and comparisons of LTS; 
two different model-checkers for various temporal logic and /r-calculus, and se- 
veral verification algorithms. Finally, CADP offers a friendly user interface and 
a visual representation of the LTS. This is very useful for an easy presentation 
of the specifications to the non-specialist people. 

The process of the construction of a LTS and its submission to CADP is the 
following. Given a B abstract system (or a refinement), the user provides a list 
of predicates 4>j. From this list, a preprocessor can compute a list of formulas 
as defined in section 3.5. Actually, the preprocessor must dialog with the prover 
of the AtelierB. The first thing to do is to compute and to try to prove the 
conditions on the guards which determine what are the events enabled in each 
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state. If n is the number of states and m is the number of events, this leads to 
n X m proofs. For those which are not proved automatically, the preprocessor 
computes the negation and submit the formulas to the prover. Here again, for 
the formulas which are proved automatically, then the decision that the event 
is not enabled in this state is guaranteed. For the other formulas, no decision 
can be taken. One possibility is to try to prove them (either the formula or its 
negation) interactively, or (as in [12]) the other possibility is to consider that 
the event is enabled. Let us remind that the principle is to compute an approxi- 
mation of the effective LTS, without loosing any possible transition. In a second 
phase, the preprocessor computes the formulas that characterize the transitions 
themselves, for the enabled events. The maximum number of generated formulas 
for determining the transitions which can occur is: 2 x n? x m. 

After this second phase, the LTS can be sent to the CADP toolbox and, 
optionally, functions of the toolbox can be applied (cycle discovery, reachable 
states, etc.). 



6 Conclusion 

In this paper, we have shown several methods to build a finite labelled transition 
system (LTS) from a B abstract system. Then, we have focus on a particular 
abstraction technique called “disjunctive decomposition” . We have shown several 
properties of this abstraction and we have applied it to a SCSI-2 [17] input- 
output case study. 

A first outcome of such a representation is to obtain a graphical view of the 
behaviour of the system. Another one is to shown that some properties hold in 
the finite model without a complete specification of the elements of the proof by 
invariant and variant, as defined in [3]. At this stage of the work, it is not sure 
whether the approach will be useful for very large B systems. The main problem 
comes from the fact that we need to prove formulas to compute transitions. An 
important aspect of the further experiments with our tool is to measure the rate 
of automatic proofs in this kind of process. Probably some tactics can be tuned 
to improve the rate obtained by a naive use of the B prover. As explained in 
[12], the construction of an LTS can be fully automatic, but we wonder if the 
approximation obtained will not be too large, because this is depending on the 
strength of the prover. So, another outcome of the study is to appreciate if the 
B prover is clever enough to build a selective LTS. 

Another research direction is to use the same machinery to prove inductive 
invariants by backward symbolic computation as shown in [5]. In that case, it is 
not necessary to give a decomposition of the global state. Instead, one gives the 
property to be proven about the system. Then, starting from the most abstract 
LTS, with one state and all the possible transitions, the tool computes what 
are the transitions which do not preserve the property. These transitions are 
removed and the state is split if necessary. At the end, if the initial states are in 
the automaton, then the tool guarantees that the property holds in the system. 
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Abstract. In this paper we show, by a series of examples, how the p- 
chart formalism can be translated into Z. We give reasons for why this 
is an interesting and sensible thing to do and what it might be used for. 



1 Introduction 

In this paper we show, by a series of examples, how the ^-chart formalism (as 
given in [10]) can be translated into Z. We also discuss why this is a useful and 
interesting thing to do and give some examples of work that might be done in 
the future in this area which combines Z and ^-charts. 

It might seem obvious that we should simply express the denotational se- 
mantics for /i-charts given in [10] directly in Z and then do our proofs. After all, 
the semantics is given in set theory and so Z would be adequate for the task. 
However, our aim is to produce versions of /r-charts that are recognisably Z mo- 
dels, i.e. using the usual state and operation schema constructs and some schema 
calculus in natural ways — ^-chart states and transitions appear as Z state and 
operation schemas respectively. Thus we aim for a Z model in the conventionally 
accepted form. We want this so that the Z model is readily understandable in its 
own right and also comparable with alternative models in Z, e.g. those that are 
part of the outcome of Weber’s framework [20] (which we will mention briefly 
again in Section 5.3). 

To make the paper fairly self-contained we start by giving a brief introduction 
to the main conceptual apparatus of this paper: the reactive system modelling 
formalism of /r-charts, the specification language Z and the Z proof tool Z/EVES. 
In each case, though, the references cited should be used by readers who wish 
to have a full and proper introduction to each topic. 

We then explain our translation via a series of examples in Sections 2 and 3. 
In Section 4 we give an extended commentary on aspects of [10] in which we seek 
to show how the concerns of that paper, which uses the technique of oracles, have 
been dealt with by our translation. We also, somewhat speculatively, consider 
extending the technique in [10] in a way which appears to combine the semantics 
in that paper with the alternative semantics given in [15]. Finally, we motivate 
the current work and look into the future. 
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1.1 /x-Charts 

^-Charts [10] are a visual representation used for the specification of reactive 
systems. They extend finite state transition diagrams by adding modularisa- 
tion through hierarchical decomposition, i.e. allowing states to contain other 
^-charts, and allow the modelling of separate communicating processes by par- 
allel composition, that is allowing two /i-charts to communicate via broadcast 
signals. The communication between /r-charts in a specification is modelled using 
instantaneous feed-back of signals. 

/i-Charts are a variant of Statecharts [2] that exclude a number of syntactic 
concepts which cause semantic problems, e.g. inter- (hierarchy-) level transitions^. 
Also /r-charts have been given a compositional semantics (and allow abstract 
specification by incorporating t.g. non-determinism) and refinement rules have 
also been given that describe a formal process of making an abstract or non- 
deterministic /r-chart more concrete [14,15]. 

The compositional semantics for /r-charts considered in this paper is that 
described in [10], though we do acknowledge there have since been alternatives 
to this proposed, as in [14] and [15]. The ramifications of these alternatives 
have not yet been fully investigated, though we make some comments on this in 
Sections 4, 5 and 6. Since we shall be introducing /r-charts via several examples 
in the sequel, we will say no more about them here. 



1.2 Z 

The specification language Z is based upon typed set theory and first-order 
predicate calculus and includes the notion of schemas used to encapsulate ma- 
thematical objects and their properties by declaration and constraint. Z is a 
model-based notation usually used to represent abstract specifications of sy- 
stems by describing observations of their state and some operations that can 
change that state (see [8], [21]). 

To give an example of Z we specify a schema named State with a single 
integer observation that is constrained to remain within a given range: 



State 

X : N 

a; > 10 
a; < 20 



InitState 

State 

a: = 11 



Z state schemas are divided into declarations, i.e. observation names (or 
labels) and their types, and predicates constraining those observations. This di- 
vision is represented graphically by a horizontal line. Two other principles of Z 
demonstrated here are the convention of initialisation and schema inclusion. Z 
specifications generally include an initialisation schema, e.g. InitState, that spe- 
cifies what happens at system startup. Schema inclusion, e.g. of State included 



^ The ZedCharts work [17] grew out of similar considerations and reservations. 
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in the declaration of InitState, is a notational shorthand for including the res- 
pective declaration and predicate of one schema into another (subject to certain 
consistency requirements between the declarations). 

Operation schemas are different from state schemas in that they include two 
observations of the state. One, known as the unprimed copy, represents the values 
of the state observations before the operation and the other, the primed copy, 
represents the values of the observations after the operation. 



Increment 

AState 

X <2Q 
x' = X + 1 



Restart 

AState 

x>20 
x' = 11 



T _Op = Increment V Restart 

The schema inclusion of AState is another convention in Z where A schemas 
are recognised to be defined as including a primed and unprimed copy of the 
schema, e.g. AState = [State, State']. Also schemas including Z\-schemas are 
conventionally recognised to be operations that change the state. All the various 
forms of schema given above are examples of Z paragraphs. 

An operation schema has a precondition which has explicit and implicit com- 
ponents, taken in conjunction, e.g. Increment has the components x < 20, a; < 20 
and X > 10; the first explicit, the last two implicit. An operation is said to be 
total when its precondition is true for all possible values of the state. If a spe- 
cification does not provide total operations then the reaction of the eventual 
implementation outside of the operation’s precondition will be undefined. This 
fact can be advantageous, remembering Z is used for abstract specification, when 
the specifier does not care to define the behaviour in some situations. 



1.3 Z/EVES 



Z/EVES [12] is a type checking and theorem proving tool for Z specifications. It 
is an interactive system in which Z specifications can be presented one paragraph 
at a time or in their entirety. Theorems can be defined and proofs attempted 
at any time. Z/EVES was developed by ORA [9] and is used here to prove 
properties about the Z translation of /r-charts, and hence to prove properties of 
^-charts. 

To give an example of using Z/EVES we evaluate the precondition of the 
schema T_Op, from Section 1.2, to show that this operation is total when applied 
to any valid observation of the state, i.e. to prove that the predicate State => 
pre T_Op is true: 



258 



G. Reeve and S. Reeves 



try State pre T^Op] 
invoke] 

instantiate x' == x + 1; 
prove by reduce] 

— > true 

The try command (first line of input) allows the user to evaluate predicates 
about the current specification. In this case the predicate says that assuming the 
constraints on this state, the precondition (calculated by the Z prefix operator 
pre) of the operation schema T_Op is always true, i.e. the operation can be 
applied to any valid configuration of the state. The Z/EVES commands on lines 
2-4 of the input instruct Z/EVES to carry out some evaluation on the given 
predicate, which is true as expected. 

2 The Translation: An Example 

In this section we concentrate on giving a series of examples which highlight 
the main features of our translation procedure which turns /i-charts into Z. The 
presentation of the procedure in detail (and its formal justification) will be given 
in a later, fuller paper. 

The /i-chart given in Figure 1 was chosen as the simplest example that 
demonstrates the following concepts: 

— several sequential automata; 

— more than one level of hierarchical decomposition; 

— instantaneous feed-back of signals. 

Some of the /x-chart conventions used in Figure 1 include: states with a double 
lined border represent the default or start state for a /x-chart, that is the state 
which is entered whenever the chart is entered; any state with a rectangular 



U 




{Sb, Sp) 



Fig. 1. A simple /x-chart 
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border is a decomposed state, that is it contains another /i-chart, referred to 
as a slave, which is active (can make transitions) while the “master” chart is 
in the decomposed state; the labels on the transitions are made up of a trigger 
and output condition separated by a The trigger is a Boolean expression 
depending on presence (and/or absence) of signals and the signals in the output 
set are those which are output if this transition happens. If the output set is 
absent then the transition has no output associated with it (we also omit the ‘/’ 
in this case); finally the small rectangular box hanging from the bottom of the 
chart contains the set of signals that are to be instantaneously fed back as input 
to all /i-charts and sub-charts within the chart to which the box is attached. The 
way in which this mechanism works will become clearer as we work through the 
examples below. 

The Z translation is presented by giving a Z description (as a state schema) of 
each state in the example /x-chart followed by a description of each transition as 
an operation schema. The correct combination of these transitions then describes 
the overall behaviour of the ^-chart. We present this example in its entirety, 
despite some aspects appearing trivial, to allow the reader the greatest chance to 
follow the translation process. Note also that since we want a uniform process, i. e. 
one that applies to all charts in the same way, there may be pieces of Z produced 
that the accomplished Z-reader will consider clumsy or naive. However, again 
for reasons of clarity of process, we will resist the temptation to simplify and 
present the Z just as the process produces it. 

Lastly we investigate the resulting Z specification using the tool Z/EVES. 

2.1 Describing the States 

The first task in the translation is to give a Z state schema, by convention of the 
same name, for each of the states in the /x-chart. This includes those states that 
represent slaves (sub-/x-charts) and those that represent atomic states. We first 
give values that will be used to name states and signals: 

^^state ;:= a I & I c I d I e I / I 5 I /i 

Signal ::= S'a | | 5c | b'd | 5e | 5/ | Sp 

Then we need a Z state which represents the whole chart together with its 
initialisation to the correct /x-chart state: 

— C/ 

■ Instate 



— InitU 
U 



cu = a 



The next states to be described, A and H, are atomic states and therefore 
are trivially described by the schemas A and H : ^ 

^ Note that in the sequel we shall usually omit explicit mention of such outermost 
charts as U since their formalisation contributes nothing to our translation. 
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— A 



— 



'■ fJ- State 

Cu = a 



'■ State 

Cu = h 



More interestingly, i? is a slave of 17 ^ . Therefore, it introduces an observation 
of the slave /r-chart’s state as well as defining what it means for U to be in the 
state 5, i.e. cu = b. Each schema that models a ^-chart (as opposed to an atomic 
state) also has an initialisation operation defined that specifies what state the 
slave is initialised to when it becomes active, that is when the master enters the 
corresponding state: 

^ 

CUt Cb '■ fj- State 
Cu = h 



— InitB 
B 



Cb = C 



Now the three schemas C , D and E are given describing the states of the /r-chart 
B. First, for the atomic states C and D: 



Cb '■ B-State 


Cb '■ B-State 


Cb = C 


Cb = d 



Notice that we don’t include the schema 5 in C or £) as may seem intuitive. 
If B were included in D then /i-chart U would be forced to be in state B after any 
transition in the /r-chart B to state D — but this then blocks modelling in /i-charts 
what are (semantically better behaved) counterparts for inter-level transitions in 
Statecharts"'. We want to allow such better behaved transitions because it allows 
modular design of /r-charts and hence a more natural and tractable modelling 
of physical systems. 

Schema E models a /r-chart and therefore has an initialisation schema: 

E 

Cb, Ce '■ fJ' State 
Cb = e 



— InitE 
E 

Ce = f 



Now schemas F and G are given for the two atomic states of /i-chart E: 

^ or — the /i-chart R is a slave of U. This view of B as both a state and a /i-chart 
(and indeed a schema) needs to be kept in mind, and when it is not clear from the 
context which we mean we make it explicit. 

Note /i-charts can allow two or more transitions to be triggered instantaneously if 
they are in different charts, including sub-charts. 
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F 



— G 



CE ■ ^^State 

CE = f 



CE ■ ^^State 

CE = g 



Given all of the state descriptions we can now go on to describe the transitions 
between these states. 



2.2 Describing the Transitions 

One of the properties of /i-charts that must be modelled is instantaneous feed- 
back. The semantics of ^-charts, as given in [10], uses a fixed-point construction 
to calculate, in an operational fashion, the overall input for a /r-chart step. In 
the Z translation we use the fact that only one transition can happen per /r-chart 
(in any hierarchy, i.e. one in U , one in B and one in E) per step, and the nature 
of the schema calculus (the effects of schema inclusions), to give a declarative 
description of the possible inputs for a step. 

The feed-back signals that are locally visible to each /r-chart in the specifi- 
cation are given by the sets lu, h and Ie defined below. The local sets can be 
read from any attached feed-back boxes in the graphical notation. The sets fjj, 
Jb and /e determine the scope (due to the hierarchy) of feed-back signals in the 
^-chart and therefore give all the visible feed-back signals for each /i-chart: 

lu=={Sb,Sp} fu==lu 

Ib == {} fs == fu U Ib 

Ie == {} /e == /b U Ie 

In this simple example the feed-back signals are common across all of the 
^-charts. 

A schema. Output, that describes the allowable output information for a 
^-chart is also given: 




The schema Output has an observation of the output signals generated by 
each ^-chart in the specification. Each of these observations represents the set 
(possibly empty) of output signals from the given ^-chart in a step and the 
union of these sets gives the overall output. The intersection of the output and 
the feed-back set gives the feed-back signals visible for the current step. 
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Now, with the states of the /i-chart and the output/feed-back mechanism in 
place, an operation schema is given for each transition. The description of the 
transitions is organised to follow the hierarchy of the example /r-chart. 

Transitions in /r-Chart [/: Firstly an operation schema. Sab, is given descri- 
bing the transition between states A and B in /r-chart U^: 




Due to the schema inclusions here, the precondition of Sab states that the 
current state of U must be A, i.e. cu = a, the overall output set is equal to the 
union of ou, ob and oe and the signal Sa must be an external input or a fed 
back signal for this transition to happen. Since the transition goes into a state 
which is also a slave ^-chart the schema included has to be the initialisation 
schema for that slave. 

Note the precondition of this transition is not yet determinable because the 
values of Os and oe are not known: it establishes a constraint on the allowable 
solutions. Sab stipulates that if the precondition is true then the /i-chart U will 
be in state B after this transition and the /i-chart B will be in state C . 

Similarly, the transition between states B and H is given by Sbh- 




The precondition allows this transition only if the signals Sb or Sp are present 
in the input or feed-back. 

The /i-chart semantics state that in the situation where no transition is trig- 
gered then the /i-chart stays in its current state. To model this in Z we provide 
another operation schema. For the /i-chart U this schema is ey: 

® Recall: Signal is a set of all external, internal {i.e. feed-back) and output signals that 
are available in the system being modelled. 
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f-U 

Cu,c'u,CB ■■ State 
input! : P Signal 
Output 

{A A Sa G input! U (o! Ofu)) 

-'{BA {Sb € input! U (o! fl fu) \/ Sp G input! U (o! fl fu))) 

c'u = cu 

OU = {} 



The precondition of this schema states that no valid transition in the /r-chart 
U is triggered. The postcondition states that the /r-chart configuration remains 
unchanged. The output, given that the chart makes no transition, must clearly 
be empty. 

There is no predicate involving H here (corresponding to the first and second 
involving A and B respectively) since if we are in state H then nothing happens 
unconditionally^ i.e. whatever the input — so the condition for nothing happening 
is, vacuously, true. Contrast with the case for A — this predicate says that if we 
are in state A then the condition for nothing happening is that Sa is not in the 
input or feed-back. 

Transitions in ^-Chart B: The transition descriptions for /r-chart B are given 
by Scd, Sdd and Sde- 



Scd 

B 

C 

D' 

input! : P Signal 
Output 

Sc G input! U (o! n/e) 
OB = {} 



— Sdd 

B 

D 

D' 

input! : P Signal 
Output 

Se G input! U (o! H/b) 
OB = { 56 } 



Sde 

B 

D 

InitE' 

input! : P Signal 
Output 

Sd G input! U (o! Pi/b) 
Ob = {} 



Notice that the preconditions of these operations say that the transitions can 
only happen if the current /x-chart is in the right state, e.g. cb = c for Scd^ and 
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any master /r-chart is in the expected state or in other words the current /i-chart 
is active, e.g. cu = b for Scd- 

As important (as we have said before) is the fact that the operation restricts 
only the after transition state of the /r-chart in which the transition occurs and 
not its master’s state. 

Next we give the e schema and another auxiliary schema, Inactives, for the 
/x-chart B : 



Cs 

Cu , Cs , Cs ■ Instate 
input! : P Signal 
Output 




B 

{C A Sc G input! U (o 
-• {D A Sd G input! U (o 
-1 {D A Se G input! U (o 
Os = {} 

c's = Cs 


c C C 



Inactives 

Cu J Cs , Cs ■ testate 
Output 

^ B 

OB = {} 

Cr = C 



The operation schema Inactives defines the action of B when it is not active, 
i.e. its master, 17, is not in state 5®. An inactive /i-chart is to remain in its initial 
state and not react to any signals. 

Transitions in /i- Chart E: The transition descriptions for /i-chart E results 
in three schemas, Sfg, es and Inactive s'- 



^fg 

B 

E 

E 

G' 

input! : P Signal 
Output 

Sf G input! U (o! H/e) 
oe = {Sp} 



— eg 

Cu ^ Cs, Ce, Ce ■ testate 
input! : P Signal 
Output 

~B 

E 

{E A Sf G input! U (o! H/e)) 
Oe = {} 

Ce = ce 



Inactive E 

Cu, Cs, CE, c'e ■■ instate 
Output 

B \/ ~< E 
OE = {} 

CE=f 



There is no corresponding Inactiveu since U is not a sub-chart of any chart and so 
will never be inactive. 
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Notice, because a /i-chart is inactive if its master is inactive, the schema 
Inactive E has the predicate ^ B y ^ E that says the chart is considered inactive 
if either its master is not active, i.e. -> 5, or it is itself inactive, i.e. -> E. 

2.3 Describing the Step 

Now all of the schemas needed to describe the step behaviour of the /r-chart have 
been provided. The predicate of the step-modelling schema Step conjoins the 
possible transitions for each /i-chart and hides each /i-chart’s component output 
observation. The schema Step is a set of bindings that describes a transition 
function for the /i-chart with respect to input: 

— Step 

Cu , c'lj, Cb, c'b, Ce, c'e : Pstate 
input?, o! : P Signal 

3 ou, Ob, oe -V Signal • 

{{Sab V 6bh V eu) A 

{Scd V Sde V 6dd V es V InactiveB) A 

{Sfg y Ce y InactiveE)) 



2.4 Using a Theorem Prover to Investigate the Z 

This section gives some examples of exploration of the resulting Z specification 
using the tool Z/EVES. 

The first two examples examine the behaviour of the /i-chart when it is in 
its initial state and the signal Sa is either present or absent: 

try Step[cu := a, cb '■= c, ce '■= f, input? := {-Sa}]; 

— ^ c'jj = b A c'b = c A c'e= f A o\ = {} 

try Step[cu := a, cb '■= c, ce '■= f, input? := {5p}]; 

— S. c'jj = a A c'b = c A c'b = f A o\ = {} 

Both of these proofs result in the desired outcome. This method could be 
used in the same way to test all transition behaviours. For example the more 
interesting configuration of the /i-chart where U is in state B, B is in state D, 
E is inactive and Se is input, can be checked as follows: 

try Step[cij := b, cb '■= d, ce '■= f, input? := {56}]; 

— c'u = h A c'b = d A c'b = f A o\ = {56} 

Other ways of examining the /i-chart include checking that there is some 
input signal set and configuration that allows a transition ending in another 
configuration valid of the system. Or, as valuably, no input and configuration 
exist that could result in a transition ending in an invalid configuration. 
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The first example gives the expected post-transition configuration and output 
and quantifies over the pre-configuration and input: 

try 3 input? : V Signal; cy , cb, ce ■ Instate * 

Step[c'jj := h, c'g := c, := /, o! := {}]; 

— > true 

That this is true can be interpreted to mean there do exist some configuration 
and some input that would allow a transition to the given configuration with 
the expected output, i.e. it allows us to test reachability. 

The next example gives a contradictory configuration and resulting output, 
i.e. we expect that the system can never make a transition ending in this confi- 
guration with this output. The expected result is therefore false: 

try 3 input? : T Signal • Step[c'u := /i, c'g := c, c'^ := /, o! := {<Sp}]; 

— > false 

A variation of this type of exploration is obtained by not quantifying over 
the starting configuration or giving the expected output. The resulting predicate 
simplifies to constraints on these observations rather than true or false. It is 
worth noting that as less fixed information is provided the more complicated 
the proof and resulting predicate become, e.g. there are likely to be numerous 
combinations of possible configurations and outputs on which a transition can 
give the expected configuration: 

try 3 input? : ¥ Signal • Step[c'ij := h, c'g := e, c'^ := g]; 

— > cjj = b A Cb = e A Ce = g ol = {} 

\/ cy = b A Cb = e A Ce = f A o\ = {5p} 

Other important properties of the specification may include the inability of 
the ^-chart to get from one state to another in one step. For example we can 
prove that there is no input that will take this /r-chart from state A to state H 
in one step: 

try 3 input? : ¥ Signal • Step[cy := a, c'jj := h]; 

— > false 

We can also compose steps together to more rigorously check reachability 
of configurations. Due to the grammar used by Z/EVES ^ this requires some 
definition of temporary schemas such as Step 2 ' 

^ Z/EVES follows the grammar of Spivey [18] which does not class schema expressions 
as expressions simpliciter, hence the definition we require cannot even be expressed 
(though see the Acknowledgements). The grammar in the proposed standard [19] 
combines the two categories, so once Z/EVES supports the grammar in the new 
standard we would be able to straightforwardly define the function we desire. 
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Fig. 2. Example 1: Causality Problems 



Step 2 = Step[il / input! , ol / o\] Q Step[i2 / input? , o2 / o\] 

try 3 il, i2 ■.'¥ Signal, cu , cb, ce ■ iLstate * ■= '=^, 0 ^ ■= g]] 

— > ol = {} A o2 = {Sp} 

More interestingly the two cases below check the reachability of a given con- 
figuration from the initial configuration of the ^-chart. We need to again define 
temporary schemas that give compositions of Step with itself three times: 

Steps = Step 2 9 Step[i3 / input! , o3/o!] 

try 3il,i2, z3, ol, o2, o3 : P Signal • 

Steps[cu ■■= a,CB ■= c,ce ■=f,c'u := h, c'^ := d,c'^ :=/]; 

— > true 

try 3il,i2, z3, ol, o2, o3 : P Signal • 

Steps[cu ■■= a,CB ■= c,ce ■=f,c'E ■= b,c'g := e,Cg :=/]; 

— > true 

Given the above examples it is easily seen how we could invent different com- 
binations to investigate more properties of the system. For example we might 
need to check there is at least one possible transition out of any valid configura- 
tion, i.e. the system is always ready to react. 



3 Avoiding the Pitfalls: Getting the Right Semantics 

This section gives some pathological examples taken from [10] which are given 
to show that the Z translation respects the semantics given for /r-charts. 



3.1 Causality Problems 

The first example is given by the /x-chart in Figure 2. 
The resulting Z from the translation is: 



— A 



B 



■ I State 

Cu = a 



'■ I State 
Cu = b 
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— Output — 
ojj : Pj^a} 
o! : P Signal 



lu == {5a} 
fu == lu 






Sab 

A 

B' 

input? : P Signal 
Output 

Sa ^ input! U (o! Ofu) 
ou = |5a} 



— eu 

Cu J Cjj : Pg^ate 

input! : P Signal 
Output 

{A A Sa ^ input! U (o! Ofu)) 

oy = {} 

c'u = C(7 



The schema Sab above demonstrates the first translation of a negated trig- 
ger expression. Negated trigger expressions are translated by a predicate, i.e. 
Sa ^ input! U (o! Ofu), that says the signal does not appear in the input (inclu- 
ding feed-back). This example (and in fact the next example) demonstrates the 
causality problems that can be introduced by negated trigger expressions. ® For 
this example, when the chart is in its initial state, there is no solution when the 
signal Sa is not input, and in this case the predicate of Step: 

— Step 

CU,c'u ■ P State 

input! , o! : P Signal 

Sab^ f-u 



is false. 

The predicate of the schema Sab is false in all cases which, as we would expect 
given the semantics for this /i-chart, means this transition can never occur. If 
the signal Sa is input the trigger condition on the transition is false causing 
the /i-chart to stay in the same state and (the operation) ey to take place. If, 
when the chart is in state A, Sa is not input then no transition is valid and the 
predicate of Step is false. The semantics for /i-charts given in [10] states that in 
the event of empty reactions (which means that the schema Step is an empty set 
of bindings in the translated Z) the /x-chart remains in its current configuration. 
Hence in both cases, Sa present and Sa absent, the Z model constrains the after 
state of the transition to be A, i.e. the configuration of the /x-chart remains the 

® The semantics given in [10] introduces the idea of oracle signals, which can be used to 
rule out solutions with such causality problems. See Section 4 for a fuller discussion 
of this. 
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Fig. 3. Example 2: More causality problems 



same. That this accords with the definition in [10] is evidence of the correctness 
of our translation. 

This can be easily illustrated using Z/EVES as follows: 
try Step[cu := a, input? := {^a}]; 

— c'jj = a A ol = {} 

try Step[cu := a, input? := {}]; 

— > false 



3.2 Causality Problems Continued 

A more interesting example is that of Figure 3. 

The behaviour of this /r-chart is non-deterministic when neither Sa nor Sb 
is input. The correct configuration of the /i-chart after a step with no input is 
either U in state A and V in state D or U in B and V in C . 

The translation gives: 



— A 



B 



— C 



'■ Instate 
Cu = a 



'■ IJ-State 
Cu = b 



■ testate 
Cv = C 



^ 

'■ Instate 
Cv = d 



Ifj == {Sa,Sb} 

fu == h 
ly == {Sa,Sb} 

fv == W 



— Output 
ou : P{5&} 
oy ■ P{5a} 

o! : P Signal 

ol = lJ{oc/, Oy} 



— S^f, 

A 

B' 

input? : P Signal 
Output 

Sa ^ input? U (o! fifu) 
ou = { 5 &} 
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ec/ 

C(7, Cy : P'gjate 

input? : P Signal 
Output 


bed 

c 

D' 

input? : P Signal 
Output 


{A A Sa ^ input? U (o! Ofu)) 
oy = {} 
c'u = Cu 


Sb ^ input? U (o! Ofy) 
Oy = {5a} 




X. y 

Cy , c'y : 

input? : P Signal 
Output 


Cu, c'u, cy.c'y : 
input?, o! : P Signal 


3 ou, Oy : P Signal • 

{{bab V €u) A 
(bed V ey)) 


-■ (C A 56 ^ input? U (o! fl/y)) 
av = {} 
c'y = Cy 



Four Z/EVES tests are given for the translation to show that the behaviour 
of the Z respects the ^-chart meaning: 

try Step[cjj := a, cy ■= c, input? := {5a}]; 

— c'jj = a A c'y = d A ol = |5a} 

try Step[cu := a, cy := c, input? := {56}]; 

— > c'l^ = b A c'y = c A o\ = {56} 

try Step[cu := a, cy := c, input? := {}]; 

— >■ if Cy = a then c'y = d A o\ = {5a} 
else Cy = 6 A Cy = c A o! = {56} 

try Step[cjj := a, cy := c, input? := {5a, 56}]; 

— c'jj = a A c'y = c A o\ = {} 

This example also demonstrates how the translated Z deals with non-determin- 
ism: it is non-deterministic when neither of the signals Sa or 56 are input. The 
resulting Step schema allows one behaviour or the other. It is not possible for 
both to occur and Step makes no decision about which should occur. 

4 Oracles 

In [10] the authors introduce the idea of oracles in order to rule out certain 
unwanted solutions that their fixed-point construction would otherwise give. 
The unwanted solutions are those which lead to causality conflicts arising from 
the presence of negated triggers i.e. causality conflicts which arise when we allow 
the absence of signals to be acted on. 

We give an example of how the oracle mechanism is used to rule out certain 
solutions. We then relate those solutions back to the ones we get in our Z model 
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Fig. 4. Illustrating oracle use 



for the same example in order to show one more aspect of the relationship 
between the two models. 



4.1 Oracles and Causality 

The example we will use is a simple variant of example 2 (which was given in 
Figure 3) where we take the negation off the trigger for the transition in V. 
(This also gives us an example of a case we have not yet explored, i.e. one in 
which both negated and un-negated triggers occur.) 

The method that [10] uses to rule out certain solutions that violate some 
causality concerns is to first rename any negated trigger -i a as -> a and then 
conduct experiments to see what the reaction of the chart is when we make as- 
sumptions about feed-back involving these new signals, which are called oracles. 
So, the oracle signals represent signals that may be fed back during any of a num- 
ber of instantaneous transitions and they were designed so that we can consider 
the reactions of the chart when signals are absent and when there are negated 
triggers in the chart. (We have seen examples of this in Sections 3.1 and 3.2.) 
The chart we are considering would, therefore, be re-written as in Figure 4. 

Now, if we want to see what its reactions are when no (external) input is 
given there are two experiments to perform: firstly we assume that Sa is in the 
set of signals generated by the chart in this step (the fixed-point for this step), 
i.e. an experiment with Sa being in the fixed-point; secondly we assume that 
Sa is never output for any reason (and so does not appear in the fixed-point) 
which means we assume that -■ Sa is in the fixed-point. The reader can see that 
the resulting fixed point of the first experiment is {Sa} and for the second the 
fixed-point is {-i Sa, Sb, Sa}. 

The result of the first experiment is not allowed as a possible behaviour of 
the chart since when we assumed that Sa would appear in the fixed-point it 
never did. The result of the second experiment is not allowed as a solution either 
since a signal (Sa) that we assumed would not appear in the fixed-point did. So, 
neither experimental solution is allowed since they each break certain causality 
constraints that it seems reasonable to impose. 

The first constraint requires that if a signal can appear (because transitions 
that produce it as output can take place) then it does: this is self -fulfilment. The 
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second constraint requires that a signal does not appear as the output of any 
transition that takes place because of the non-appearance of that signal: this is 
consistency. 

So, how is it that we disallow the same causally suspect solutions that the 
oracles mechanism does, but without using anything like that mechanism? The 
reason lies in the different ways the semantics are given. In our case, we rely 
on the usual semantics of set theory and give the semantics in a declarative 
fashion. In the case of [10] the semantics is given by a fixed-point construction, 
where each ‘iteration’ towards the fixed-point models the idea of one transition 
possibly leading to others once its output has been instantaneously fed back as 
input, this process continuing until no further transitions are triggered, when 
the fixed-point is reached. 

In more detail: when computing the fixed-point, the absence of a signal has 
to be recorded in order for the causality test to be meaningfully performed. 
Otherwise, the reason that at one stage the signal is not in the feed-back set (the 
so-far-computed fixed-point) might be either because it simply hasn’t appeared 
yet or because it must not appear. When we reach the fixed-point we need (for 
the causality test) to tell these two situations apart. Hence the oracles: -■ a 
appearing means that a must never appear; -■ a not appearing entails no such 
condition. ® 

In our case, to get the same causality condition, we do not need the oracles. 
This is because our translation imposes global constraints on the possible so- 
lutions; constraints which are ‘in force’ permanently. That is, we declare what 
constraints a solution must satisfy and then rely on the semantics of Z to en- 
sure that only acceptable sets are allowed as solutions, according to the usual 
meaning of the existential quantifier that appears outermost in our translation. 
Thus, if some transition is triggered only when a is absent, but some other tran- 
sition adds a to the solution set then, since not both of these conditions can be 
satisfied, such a solution is ruled out. In the oracles case, since the solution set is 
essentially built iteratively (gradually computing the fixed-point) and since no 
constraints are passed between the iterations, the ‘global’ fact that a has been 
banned by the triggering of one transition must be recorded in order that the 
causality condition can be checked; simply leaving a out of the set will not do 
as it does not distinguish finely enough between two possibilities. 

4.2 Extending the Use of Oracles 

The semantics given in [15] differs, as we have mentioned a few times, from that 
in [10]. One way that this difference emerges is on the ^-chart given in Figure 5. 

In the absence of any external input, the semantics in [10] means that this 
chart does nothing. In contrast, the semantics in [15] means that chart is non- 
deterministic: it can either do nothing or both transitions can be triggered. Our 
translation process produces a description of the chart which agrees with the 
latter interpretation. 

® This relationship between declarative and procedural semantics closely mirrors the 
two ways of giving semantics to Prolog programs. 
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Fig. 5. ^-chart with no negated triggers 



When we investigate the reasons for this we see that our constraints on 
solutions in the translation correspond to replacing not only negated triggers 
with negated oracle signals but also doing the same with un-negated trigger 
signals. Our conjecture (which we have shown holds for the examples in this 
paper) is that extending the use of oracles in this way would, in general, extend 
the solutions given by the semantics in [10] to those given by the semantics in [15] 
while still ruling out the solutions that offend certain sorts of causality scruples. 

5 Uses 

Having presented a translation of /r-charts into Z we want in this section to 
motivate this activity, which we do by giving several positive results of such 
an activity. One overall result is that the translation has opened-up and made 
possible all sorts of links and comparisons with work on Z and, increasingly, 
work in the wider area of program development. 

5.1 Alternative Views of the Solution 

Giving two different views, via the different languages of /r-charts and Z, of a 
solution to a problem can often give us another chance to see if we have the 
right model of a given system. Different aspects of the model may come to light, 
given the different expressions in the different languages, which might lead us to 
see mistakes in the model. 

Some properties of the system being modelled might be more readily apparent 
in the Z view than in the chart view (and vice versa, of course). 

5.2 Proof Instead of Model Checking 

We have proof available for Z (via, for example, Z/EVES) which means that, 
via the translation, we can reason about the reactive model of our system. This 
forms an alternative to the sorts of model checking that staying with the /r-chart 
model would give. 

The importance of proof (or deduction) in contrast to model checking has 
recently been explored by Pnueli [11], where he makes the following points: 
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“ deduction is based on induction whereas model checking (which he charac- 
terises as exploration) is based on computing a set of reachable states; 

— deduction uses a more expressive language, leading to good ways of expres- 
sing, especially, parameterised systems; 

— deduction-based methods have better scalability, e.g. as a system increases 
in size we may be able to rely on the same (or same size of) inductive proof 
as for the original, smaller system — so the amount of work does not increase. 

Whatever the pros and cons of each method (and whether we accept Pnueli’s 
points or not), it is certainly the case that having both model-checking-based and 
deduction-based methods at our disposal to investigate systems is advantageous. 
This would clearly be the case when we come to proving invariants of systems. 

5.3 Alternative Solutions to the Problem 

Following Weber’s approach in [20], of specifying the problem from a Z perspec- 
tive and a Statechart (for us /r-chart) perspective (and so having two different 
models of the problem, in contrast with the situation in Section 5.1 where we 
had two expressions of the same model), and then performing our translation 
on the /i-chart model, would allow us to directly compare the two models. We 
could also more directly check the consistency of the two models if they are both 
in Z. 

6 Future Work 

6.1 Commands 

In line with the work in [15] and [16] we will add commands to the transitions. 
The idea of this is to allow the updating of values associated with the chart. For 
example, if the chart takes a transition labelled (along with the usual trigger 
and output signal set) a := a + 1 then the value of a is incremented. 

The triggers can also be extended to allow Boolean combinations of expres- 
sions involving such values as a, as well as the input signals as currently. 

These extensions allow us to model such things as clocks (where the current 
time, for example, is represented by some value which is incremented by one 
sub-chart and used by others) or mechanisms which have to wait for certain 
external values to reach required levels before performing their tasks. Again, the 
external values (say the level in a tank of liquid) can be updated and used by 
sub-charts. 

6.2 Correctness of the Translation 

In this paper we have endeavoured to illustrate the translation process, show 
some of its properties and mention some motivation for it. It still remains for us 
to show that the translation is correct by showing that, for each construct of the 
charts, its semantics is the same as the semantics we get going from that chart 
construct via the translation to Z and the Z semantics. Given that we have a 
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compositional semantics for both formalisms this strategy seems to hold some 
hope, especially in the light of the transition semantics given in [15]. This is in 
a form that is closer to our Z form and which has already been shown to be 
equivalent to the original semantics in [15]. 

6.3 Refinement 

[14] and [15] present a refinement calculus for /i-charts based on a relationship 
of inclusion, i.e. (roughly) S 2 refines is defined by 152 ]j C |5i]. This is also 
the situation with our notion of refinement in [3], so investigating the relations- 
hips between these two notions of refinement would be interesting. In our work 
schemas are sets of bindings which represent state-and-signal combinations and 
in the /r-charts work they are sets of state-and-(input/output) signal tuples, so 
there are close similarities there. 

Since we are dealing with models for reactive systems we also plan to investi- 
gate the problems and solutions proposed in [1], which relate to the introduction 
of internal transitions, as often happens during a refinement step. 

6.4 A Logic of /x-Charts 

We will develop a logic for ^-charts, along the line of our logics for Z [4] [5] [6]. 
We expect to use the Z translation to at least suggest how this logic should look, 
if not use the translation to induce the /i-chart logic from the Z logic. 

6.5 Developing Implementations 

Using the work on program development from Z, as in [3], and the translation 
given here, we will investigate program development from reactive specifications 
as given by /x-charts. 
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Abstract. An operational semantics for a significant subset of the Verilog Hard- 
ware Description Language (HDL) has been developed. An unusual aspect of the 
semantics is that it was formulated as a Prolog logic program. This allows the pos- 
sibility of simulating the semantics. In addition, a literate programming style has 
been used, so the semantics can be processed by the HTgX document preparation 
system with minimal and fully automated preprocessing. Bringing together the pa- 
radigms of operational semantics, logic programming and literate programming 
in this manner has proved a great aid in a number of ways. It has helped improve 
the understanding of the semantics, in the formalization of semantic aspects left 
informal in the original mathematical formulation of the semantics, and in the 
maintenance of the formal semantics and its associated informal description. 



Civilization advances by extending the number of important operations which 
we can perform without thinking about them. 

Introduction to Mathematics (1911) ch. 5 
Alfred North Whitehead (1861-1947) 



1 Introduction 

Traditional mathematics is written in a form designed for human assimilation together 
with pen and paper transformation. The most that could be hoped of a mathematical 
description in the past was that it might be typeset and printed (a time consuming process 
and of great expense). The advent of computers has meant that typesetting is now easy and 
cheap, even in the home. The ability to produce tools to aid transformation (either proof 
or calculational in style) is also possible, although this has proved difficult due to the 
pedantic and low-level nature of computers compared to abstract mathematical human 
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thought. The presentation of proofs is problematic even for human readers [30]. As well 
as transformation, computers also allow a mathematical description to be “executed” in 
some cases [13]; of course, it is this with which the art of computer programming is 
chiefly concerned. 

However, an important feature of a mathematical description, model or specification 
[6] is that it is not necessarily executable [17], even though some contend that it is 
helpful for it to be so [13]. An animation of a specification can help in understanding, 
just as formal reasoning can too, and in a complementary manner. Here we accept that 
a specification of a semantics is not normally directly executable. This is especially 
so if it is desirable to include non-deterministic aspects in the description; but if the 
non-determinism can be limited in a finite way, it is sometimes possible to model it 
successfully in a usefully executable manner. 

Non-determinism is particularly helpful in the formulation of the meaning of parallel 
program threads since the exact ordering of interleaving of parallel execution of processes 
may not be known. This is important in the simulation of hardware since hardware 
systems are naturally parallel. Hardware may be thought of as an (often large) number of 
parallel and interconnected components, all constantly “executing” some (often simple) 
function. 

In this paper we consider the combination of a mathematical description (semantics) 
and an executable program in a form that does not compromise either aspect more than 
is necessary. In addition, we use a style of documentation that allows this mathematical 
and executable description to be embedded and interleaved with an associated informal 
description. Having a single source for these three aspects greatly aids in their main- 
tenance and consistency as all three are developed. The process of producing a formal 
specification is as important, if not more so, that the final specification itself in gaining 
understanding of the system involved [ 1 ] . 

1.1 Operational Semantics 

There are a wide variety of semantics that have been developed to aid the mathematical 
description and specification of computer-based systems. These include denotational, al- 
gebraic and operational styles. Some effort has been made to demonstrate the relationship 
between these styles, especially with respect to the definition of different programming 
paradigms [24]. 

The style of operational semantics was originally formulated by Plotkin about two 
decades ago [34] and is still accepted as a useful semantic paradigm [33]. An operational 
semantics consists of a set of transition rules each of which may be applied if a condition 
is met. If more that one rule can be applied at a particular time, the specification is non- 
deterministic in that any of the applicable rules may be followed. The sequence of 
transitions may be terminated (normally indicated by a special program “e”). 

The adoption of an operational approach is a natural one, especially for engineers 
used to the execution of an artifact in some form. The complete set of possible steps 
at any given time are considered. A potential disadvantage of this approach is that we 
may be overwhelmed with the mass of detail involved in the execution. However, it is 
possible to project just the steps of importance if necessary in any trace of the execution 
that may be of interest. 
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1.2 Logic Programming 

Logic programming allows the specification of relations in a natural manner. With good 
judgement and an understanding of the procedural reading of logic programs, such a 
description can also be executed. 

The Prolog language [11] is an early and still widely used general purpose logic 
programming language. It is an excellent rapid-prototyping language which can be ap- 
plied in many areas, including digital hardware circuits [10]. In particular, it allows the 
execution of relations in a possibly non-deterministic manner, which can be especially 
useful in the modelling of parallel systems. Once the relations given in a specification 
are encoded in Prolog, the execution proceeds using a simple depth-first left to right 
search, depending on the order of the clauses used for the encoding. It is important to 
constrain any non-determinism in a finite way if termination is to be ensured. 

Prolog includes a pseudo-clause called op(. . . ) that allows the definition of infix, pre- 
fix and postfix operators with a specified precedence and also left or right associativity 
if required. This facility, although not extensively used by many Prolog programmers, 
allows a Prolog program to follow the form of an existing mathematical definition con- 
sisting of a set of relations in a fairly direct manner. The encoding of the relations 
themselves is typically of the same order of size as the original relations. Inevitably, 
most mathematical relations include constraints on numbers, sets, etc. Prolog provides 
simple integer arithmetic and support for lists that can be used to encode sets in a sim- 
ple manner. Normally some extra clauses are required for encoding the constraints, but 
typically these can be of the same order of magnitude in size as the original relations 
themselves. 

1.3 Literate Programming 

The “literate programming” style of Knuth [28,29] is a useful aid to the maintenance of 
a formal description (be it a program or a more general mathematical formulation) as 
part of an informal document. Most programming languages expect input to be in the 
form of source program except where portions of the input file are explicitly marked as 
comments in some way. 

In the literate style, the source file is considered as a document in its own right, 
containing portions of program (or mathematical description) only in explicitly marked 
sections. This allows documentation to be maintained in the same location (file) as 
the formal notation (e.g., as is normal using the Z notation [1,6]), aiding the goal of 
consistency between them during development. 

Specifically, in the case of Prolog, text between /*...*/ is normally considered to be 
a comment. Instead we can view text between */.../* as sections of Prolog program; the 
rest is the associated documentation. Here we choose the BTeX document preparation 
system [31] as the mechanism to maintain and print the document within which the 
mathematical description resides. 

It is likely to be desirable to omit some support clauses required for the program from 
the final printed or displayed documentation. A convention of marking these clauses in 
a manner that is still recognized by the Prolog system as comment delimiters can be 
chosen (e.g., -*/. . . / *-). It may also be helpful to mark up some Prolog code within 
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comments as far as the Prolog system is concerned, but which should be included in 
formatted form in the documentation. Section delimiters such as *+/. . . /+*, which will 
not be recognized as having any special meaning within comments by Prolog, can be 
used to indicate such sections. 

The original Prolog source file may be processed using a simple script to convert 
the */. . . /* sections (and *+/. . . /+* sections) to the \begin{. ..}... \end{. . . } en- 
vironment sections required by BT]^. The -*/. . . /*- sections need to be deleted or 
converted to comments by adding a “7.” to the start of all the lines in these parts 
of the file. The extra “/*” at the start of the Prolog source file and “*/” at the end, 
required to satisfy the Prolog system, must be removed during the processing of the 
document. In addition, a number of the Prolog operators (functors) can be converted to 
more mathematical symbols (using fflgX macros) to aid readability. 

For comparison, consider a small Prolog program fragment: 

*/ 

par(S) seq(S) . 

par(Sl//S2) seq(Sl) , par(S2) . 

/* 

This is the form in which the semantics is maintained by the developer. The equivalent 
automatically generated document source for this fragment is the following rather 
unreadable sequence of instructions: 

\ [\begin{array}{@{}l@{\ : >c@{\ : }1@{» 
par(S) \ ; \ ; \Leftarrow\ ; \ ; seq(S) . \\ 

par (S_l I I S_2) \ ; \ ; \Lef tarrowX ; \ ; seq(S_l) , par(S_2) . \\ 
\end{array}\] \Endprog 

This ugly description need never normally be viewed. The matching formatted ETeX 
output is the following much more mathematical and readable form: 

par{S) <J= seq{S). 

par{Si II S 2 ) seq{Si),par{S 2 ). 

This is the description available for documentation purposes, intended to be read by 
humans. 

1.4 Hardware Description Languages 

Hardware Description Languages (HDLs) are used to specify electronic circuits, espe- 
cially for digital systems. Two of the major HDLs in use are VHDL (Very High Speed 
Integrated Circuit (VHSIC) Hardware Description Language) and Verilog [14]. Both 
VHDL and Verilog have IEEE standards associated with them [25,26]. 

The formal semantics of VHDL has been studied quite extensively [8,12], but that of 
Verilog less so, even though VHDL is probably a more complex language than Verilog. 
Gordon has investigated the formal semantics of Verilog [15,16], but has considered a 
relatively small subset of the language. An OVI (Open Verilog International) Formal 
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Verification Standards Working Group has been established with an aim to ensure in- 
teroperability among formal verification and other tools [35]. This is concentrating its 
effort on a synthesizable Verilog subset. 

Combinational Verilog programs have been explored formally [37]. In addition, 
an operational semantics [34] for a fairly substantial subset of the language has been 
formulated [36]. Subsequently this semantics has been refined in a paper by He and Xu 
[20]. More recently, a Duration Calculus semantics for Verilog has been formulated [38]. 

An advantage of the availability of an operational semantics for a language is the 
increased understanding and the possibility of formal reasoning that this brings. A di- 
sadvantage is that the semantics cannot necessarily be directly animated. An operation 
semantics can allow non-determinism, which is advantageous in a specification, but po- 
tentially problematic in a simulator where one execution path must normally be selected. 

In this paper, we consider a revised version of the mathematical operation semantics 
description in [20] that has been formulated using Prolog, with additional formaliza- 
tion of parts left informal in the original semantics. The semantics was developed using 
Knuth’s literate programming style as a single document that is available as a technical 
report containing the full semantic description [2]. Here we present parts of this de- 
scription, concentrating especially on aspects omitted from the original mathematical 
description. 



2 Verilog Operational Semantics 

2.1 Dynamic Type-Checking 

Prolog is essentially an untyped language. This is one of its powers in modelling ma- 
thematical relations, since much mathematics is used in a rather loosely typed manner, 
and is also one of its weaknesses, since type-checking can be used to help avoid errors 
in complex formal descriptions; hence its inclusion in most computer programming lan- 
guages (used to produce formal descriptions that also have the convenient property that 
they are executable). 

It is possible to use Prolog itself to do type-checking of structures dynamically in 
the form of assertions [23] during the Prolog program execution. Indeed, many type- 
checkers work in a similar way to Prolog interpreters, using resolution to infer types of 
expressions from other expressions in which the types are known. 

In the case of Verilog, at the top level programs may be considered as a number of 
sequential programs running in a number of parallel threads: 

par{S) <;= seq{S). 

par{Si II S2) seq{Si),par{S2). 

Note that we use the more mathematical reverse implication (- 4 =) instead of the Prolog 
“ : in the clauses presented in this paper. indicates conjunction within a clause 

and indicates the end of a clause. Variables in Prolog are indicated by starting with 
a capital letter. We maintain this convention here, even if Greek letters such as S are 
sometimes used. 



282 



J.P. Bowen 



Sequential programs (in the subset of the Verilog language modelled here) consist of 
assignments, delays, programs guarded by events, standard conditional “if” statements 
and iterative “while” loops, and sequential composition of two or more sub-programs. 
Additionally, sequential programs may be terminated (indicated by the special program 
“e”). We also allow macro definitions for sequential programs so that further derived 
constructs may be included (see later for some examples). 



seq{V = E) <^= variahle{V),expr{E). 

seql^N) <!= integer(A). 

seq{@G-P) guard{G) , seq{P) . 

seq{±± EB ■ P else Q) <^= bool(EB), seq{P), seq{Q). 

seq{vh±le EB ■ P) <^= bool(EB), seq{P). 

seq{P \ Q) ^ seq{P) , seq{Q) . 

seq{t). 

seq(X) <= (X = P), seq{P). 



The variable{. . .) clause to check for a variable name will be defined later. The built-in 
integer(. . .) clause is provided by Prolog systems as a check for an instantiated integer 
value. The sans serif font is used to indicate such standard built-in pseudo-clauses used 
in the rest of this paper. 

Note also that the Prolog parser does not allow hidden infix operators. Hence the 
explicit used of in some of the constructs above and later in this paper. Rather than 
coding a parser explicitly, we use the in-built parsing mechanism of Prolog. This means 
that we have to allow some deviation from the actual concrete syntax of Verilog, but it 
saves us the trouble of building a parser explicitly for the rapid-prototype. We simply 
define the Verilog program operators to be used with appropriate precedence, pre/in/post- 
fix, and associativity using Prolog’s op(. . .) pseudo-clause. If required, a separate pre- 
processor to take an actual Verilog program and convert it to a form acceptable directly 
by Prolog could be constructed. 

Integer expressions follow the standard style in many programming languages. Here 
we allow integers, variables, addition and subtraction as an example: 



expr{N) integer(A). 

expr{V) <;= variable(V). 

expr{Ei + E2) <J= expr{Ei), expr{E2). 

expr{Ei — E2) <J= expr{Ei), expr{E2). 



Boolean expressions are also required and we include some example operators below. 
Integer expressions are also allowed, with the assumption that non- zero values are con- 
sidered “true”. 
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6oo/(true). 
&oo/(false). 
bool{\EB) <= 
bool {El = E2) 
bool {El ^ E2) 
bool{Ei > E2) 
bool{Ei < E2) 
bool{EB) <t= 



bool{EB). 

<t= expr{Ei), expr{E2). 
<t= expr{Ei), expr{E2). 
<;= expr{Ei), expr{E2). 
<;= expr{Ei), expr{E2). 
expr{EB). 



Event guards may involve a check for a change in a variable, or an explicit check for 
positive or negative edges (change) in a variable, or a disjunction of such events: 



guard{V) <t= variable{V). 
guard{posedge V) <t= variable{V). 
guard{negedge V) <t= variable{V). 
guard{Gi or G2) guard {Gi), guard {G2)- 

The variable state is modelled as a table (set) of pairs of values consisting of a list the 
variable names V each associated with an integer value N : 



table{{)). 

table{{{V = N) \ T)) variable{V),\nteger{N), teble{T). 



We use (. . .) for lists (normally written [. . .] in Prolog) for consistency with the opera- 
tional semantics on which this is based [20]. Thus {Head \ Tail) indicates a non-empty 
list with Head as the first element and Tail as the rest of the elements (if any). () denotes 
the empty list. Lists are normally used to model sets and other data structures in Prolog 
since they are conveniently built into the language. 

The above definitions allow the type-checking of an instantiated system state for 
both sequential and parallel programs. The state for a sequential program consists of a 
tuple (modelled as a list in Prolog) with two components, the (sequential) program S 
to be executed and the state of the system variables E. The state for a parallel program 
includes two additional components, an extra state component for use in event detection 
Eq and an integer label I to indicate which parallel thread is being executed (zero for 
none) at any given time. 



seqtype{{S , E)) seq{S),to-ble{E). 

partype{{S , E, Eq, I)) <^= par{S),to-ble{E),to.ble{EQ),\nteger{I). 

The partype clause can be used to dynamically check the state of the entire system at 
each step of execution, helping to avoid errors in the simulator. 



2.2 Language Features 

The meaning of each Verilog language feature is modelled as one or more transition rules, 
consisting of a condition under which the rule is valid (possibly true if no constraints 
apply), and then the transition itself. The transitions are defined use various sorts of arrow 
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relations, each defined on a tuple of state components before and after the transition. We 
often follow the convention of adding a prime to names of after-state components 
(as in the standard Z notation style [1,6]). These rules all take the following form: 

Condition 
State — > State' . 

All the various rules are composed together disjunctively (in the standard Prolog style) 
so that any rules that apply will be executed by the underlying Prolog program. They are 
also composed so that overall execution trace runs can be followed. For further details, 
see [2,5]. 

For the standard sequential features of the language, only the program and state 
variable components are required in the specification of transition rules. Procedural 
assignment overrides the state value associated with a variable V with the new value 
established by the expression E. The program is then terminated (indicated by e). 

E' = E®{V = E) 

{V = E,E)^ 

The encoding required for the “ 0 ” overriding operation will be explained later. 

The delay operator # allows a delay of N time units (typically clock cycles in 
hardware). There are two possibilities. Firstly the delay may terminate successfully and 
unconditionally: 

true 

#A -iNy^ e. 

Secondly (and non-deterministically), the program may execute for some number of 
delay units less than the maximum specified: 

0<N' <N A T = N -N' 

#A'. 

Note that Prolog cannot resolve arithmetic expressions to their values in parameters, 
unlike most other programming languages; hence the use of T above to hold the value 
of N — N' . We also explicitly constrain the delay to be greater than zero to ensure that 
progress is made. Otherwise time may “stand still” in the simulation and the program 
may never terminate as a result. If this is not an issue, we could relax this constraint and 
allow zero delays if required. The calculation of N' is encoded (later) to return smaller 
values first so that maximal time progress is made if possible. 

Events are another non-deterministic aspect of Verilog. There are three possibilities. 
Firstly the event may occur. This is determined from a change of state from Ei to E 2 
which must be provided to this clause: 

(A'1,272) 1= Event 



@Event-S -{E\^S 2 )-A S. 
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Note that at the time of invocation of this clause, both Ei and E 2 will be instantiated 
because of the way the clause is used by the rules for parallel composition later. This 
subtlety is not immediately obvious from the operational semantics, but in practice helps 
considerably with the implementation. 

Of course, it is possible that the event does not occur, in which case there is no change 
of program state: 

{Ei,E 2 ) y= Event 

@Event-S -(27i, £' 2 )— >■ @Event- S . 

Alternatively, time may advance, with no change in the program state: 

true 

@ Event -S -(_T)-a @ Event- S. 

Note the prefix used in the _T time Prolog variable (not to be confused with a Verilog 
variable) above. At this level we do not know (or even care) how many time units the 
program will advance. Thus _T could take on any value and is the only occurrence of 
this Prolog variable in the clause. The prefix indicates to the Prolog system that we 
know this fact. Otherwise a warning message is issued by most Prolog systems when 
the program is loaded. 

Verilog includes a fairly standard conditional “if” statement and “while” loop. For 
sequential composition of two programs, if the first program terminates successfully, we 
can proceed to the second one immediately. Alternatively, partial progression of the first 
program is possible. The transition may allow time to pass or may involve events. The 
transition rules for these constructs may be found in [2,5]. 

As well as sequential constructs, Verilog also includes parallel composition of se- 
quential program components. Here we must deviate slightly from the operational se- 
mantics on which this is based since it uses informal “|| ... ||” notation to indicate a 
set of indexed sequential programs running in parallel [20]. Thus we must use two or 
three clauses in place of each of the five original ones to cover the base case and one or 
more inductive cases. The associated transition rules must deal respectively with ente- 
ring, remaining in, and exiting sequential program executions not involving time delays 
or events. These are referred to as “instantaneous sections.” For details of these rules, 
see [2,5]. 

If no sequential program is engaged in an instantaneous section and all the parallel 
sequential program threads are willing to engage in an event transition, this may occur 
as a transition: 

s^Eo,sy^ S' 

{S,E,Eo,0) 

{SuE,So,0) 

{S2,S,So,0) 



(5',r, 0,0). 

(50 r, 0,0) A 
(50 0,0) 



(5i ||52,r,ro,o)^(5( II 50 r, 0,0). 
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Alternatively, if no sequential program is engaged in an instantaneous section and all the 
parallel sequential program threads are willing to engage in allowing time to progress 
by T time units, then a timed transition can occur: 

S-{T)-^ S' 

{S,E,0,0)^Ty^ {S', E, 0,0). 

{SuE,0,0)^Ty^{Si,E,0,0) A 
{S2,E,{),0)^Ty^ {S^,E,{),0) 

(5i II 52, 2 :, 0,0)^ {S{ II 5', r, 0,0). 

The above clauses, together with those for entering, remaining in and leaving an instan- 
taneous section, cover the parallel transitions given in the original operational seman- 
tics [20]. 

2.3 Macro Definitions 

The full set of transitions includes some additional rules left informal in the original 
semantics [2]. One such aspect is the addition of derived program constructs, based on 
existing program constructs. To allow this for sequential program components, we can 
add a macro expansion facility as an additional rule: 

= P) 

(X,E)^ {P,E). 

Now we can include additional sequential program constructs as macro definitions. For 
instance, we can define a program block: 

begin S end = S. 

The “forever” construct of Verilog executes a program repeatedly in an infinite loop: 
forever 5 = while true-5. 

The “for” loop is normally used for a known finite number of iterations, and can also 
be defined in terms of the while loop: 

for {A ; C ; S)-P = A ■, while C-(P ; 5). 

Other constructs include a “case . . . endcase” statement which may be defined in terms 
of the conditional if statement. It includes a “default” sub-program for execution if 
none of the cases are true: 

case Sel-{N : P ', Q) endcase = 

if Sel = N ■ P else (case Sel- Q endcase). 

case _5e/- (default : P) endcase = P. 
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2.4 Constraint Clauses 

The top part of a transition rule consists of constraints that need to be satisfied for the rule 
to be applied. In a mathematical operational semantics, this may be standard predicates 
requiring no further elaboration for the mathematically competent reader. However, to 
allow the transition rules to be executed on a computer, these constraints must be encoded 
in some form. 

We adopt the standard Constraint Logic Programming (CLP) convention of enclo- 
sing constraint conditions within curly brackets . .}” [32]. We must encode all the 
conditions we need for this particular set of rules using further clauses. Fortunately this 
proves to be relatively simple; the clauses needed are in fact no larger than the original 
rules themselves. 

A true constraint is no constraint at all. We encode this by simply adding this fact 
to the set of constraint rules so Prolog will “execute” it successfully: 

{true}. 

On the other hand, the false constraint is impossible to satisfy. We can implicitly encode 
this by simply omitting it from the set of Prolog constraint rules. Alternatively, if we 
wish to be more explicit, we can use the built-in fail pseudo-clause that can never be 
satisfied: 

{false} fail. 

It is desirable to allow multiple constraints. In particular, the conjunction of conditions 
in rules is important. Here we can simply use the in-built conjunction of Prolog (the 
operator): 

{H A T} ^ {H},{T}. 

If required, disjunction may also be encoded directly in Prolog by simply using two 
clauses: 

{H V _T} ^ {H}. 

{_H V T} {T}. 

Delays require the non-deterministic generation of numerical values between minimum 
and maximum (known) time delays. We encode this as follows: 

{No < fVi < N2} <= 

{Min = Nq + 1 A Max = N 2 — 1 A Ni G Min. .Max}. 

The operator gives all the possible values, if there are any, in ascending order from 
Min to Max. 

We encode > and > to simply check the ordering of two integer values: 

{Ai > N 2 } <= integer(Ai), integer(A 2 ), Ai > N 2 . 

{Ni > N 2 } integer(Ai), integer(A 2 ), Ai > A 2 . 
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Set membership may be encoded using the standard member {. . .) clause, available in 
many Prolog systems. If this clause is not available, it is very easy to encode and is 
included later for completeness. 

{X € S} <;= member{X , S). 

The non-deterministic membership of a number range is encoded as a base case and an 
inductive case: 

{Min € Min. .Max} <J= {Max > Min}. 

{iV € Min. .Max} <^= {Max > Min A N\ = Min + 1 A iV € N\..Max}. 

It is assumed that Min and Max are instantiated and all the possible values of N (if any) 
are returned (in ascending order as previously mentioned). 

Equality is designed to handle numerical expressions. It is assumed that the right 
hand side E is known (instantiated) and the left hand side N is to be calculated: 

{N = E} <= eval{E,N,{)). 

The eval {. . .) clause will be defined later. 

Checking for inequality is done using Prolog’s negation as failure [9]: 

{Xi X 2 } <= ~'(Xi = X2). 

Prolog’s negation as failure must be used with care. Essentially if the (Prolog) variables 
are instantiated at the time of invocation, this form of negation can be used safely. 

Procedural assignment allows the overriding of state with a new (Verilog) variable 
value. Eirst the expression E on the right hand side is evaluated and then this value is 
used to override the original state to produce a new state for all the variables: 

{E' = E®{V = E)} eval{E , N , E), override{{V = N), E, E'). 

The if and while constructs require the Boolean condition to be evaluated in an envi- 
ronment including all the values of the variables at that point. The positive and negative 
conditions need to be covered for each of the possible cases: 

{EB-{E)} <^= evalbool{EB, true, E). 

{-> EB-{E)} <^= evalbool{EB, ta\se, E). 

The detection of events must be encoded, and this is done as separate clauses (see later): 

{EE \= Event} <= EE ^ Event. 

We can use negation as failure to encode the non-occurrence of events: 

{EE y= Event} <= -'(EE |= Event). 

Any of the various types of transition may be included as conditions: 
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^ seq{S),S^So,SU S'. 

{S-{T}-^S'} ^ seq(S),S -{T}-^ S'. 

{5 — >■ 5'} <;= seqtype{S), S ^ S'. 

{5 T^-} seqtype{S),->{S ^ -^')- 

{S-{T)-^S'} <= partype{S),S -{T)-^ S'. 

{S — > 6"} <t= partype(S), S — > S'. 

Note that we do dynamic type-checking above for safety. This is especially important 
(essential) when negation as failure is used, as in one of the cases above. It is not essential 
in the other cases. 

Macro definition may be included as constraints: 

{X = P} ^ (X = P). 

This completes the encoding required for the various constraints that can be included as 
conditions in transition rules. 

2.5 Support Clauses 

During the definition of the . .}” constraint clause, a number of additional Prolog 
clauses were used. These are defined in this section. 

Firstly we need to be able to evaluate Boolean expression in an environment E 
containing the values for all the variables. Evaluation of false and true is easy: 

evalbool{fa\se, false, -E). 
evalbool{true, true, _X) . 

Boolean negation is straightforward: 

evalbool{\EB , false, E) <^= evalbool{EB , true, E). 
evalbool{\EB , true, E) evalbool{EB , false, E). 

We can use Prolog’s unification and built-in arithmetic inequality operator to encode 
equality of arithmetic expressions: 

evalbool{Ei = i? 2 ,true, 27) <^= 

eval{Ei,N , 17), eval{E 2 , TV, 27). 

ewa/&oo/(i7i = T72, false, 27) <^= 

eval{Ei,Ni,E), eval{E 2 , N 2 , E), Ni ^ TV 2 . 



Negation may then be used to code inequality: 

evalbool{Ei ^ E 2 , B , E) <;= evalbool{\{Ei = E 2 ), B , E). 

Arithmetic comparison operators can be encoded using Prolog’s built-in arithmetic sup- 
port as required: 
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evalbool{Ei > E 2 ,true, S) <^= 

eval{Ei, Ni, E), eval{E 2 , N 2 , 27), Ni > N 2 - 

evalbool{Ei > i? 2 , false, 27) <^= 

eval{Ei, Ni, 27), eval{E 2 , N 2 , 27), 7Vi < N 2 - 

evalbool{Ei < 772, B, 27) ^ evalbool{E 2 > Ei,B,E). 

We can easily allow integer expressions to be included as Boolean expressions by con- 
sidering a value of zero as false and any other value as true: 

evalbool{E , false, E) <= eval{E,0, E). 
evalbool{E , true, E) <;= eval{E, 1^,27), 1^ ^ 0 . 

Further operators, such as Boolean conjunction and disjunction may he encoded as 
required. 

As well as Boolean expressions, integer expressions are also needed. These may be 
a simple variable, in which case the value in the environment is used: 

eval{V,N,E) variable(V), member{{V = N) , E). 

If the variable is not in the environment, we assume it has a value of zero: 

eval{V,0,E) <^= variable{V),^member{{V = -N),E). 

The expression may also be a simple integer: 

eval{N , N ,_E) <J= integer(A). 

We can encode arithmetic operators such as addition and subtraction using the equivalent 
built-in Prolog operators: 

eval{Ei + E 2 , N , E) 

eval{Ei,Ni, 27), eval{E 2 , N 2 , 27), N \s Ni + A 2 . 

eval{Ei — E 2 , N , E) <^= 

eval{Ei,Ni, 27), eval{E 2 , N 2 , 27), N is Ni — A 2 . 



Further operators may be added as required. 

Events involving the change of state of variable may involve a positive edge (here 
assumed to he any increase in the value of a variable) or a negative edge (a decrease in 
the value of a variable): 

(27i, 272) ^ posedge E <^= 

member{{ V = Ni), 27i), member{{ V = N2), E2), N2 > TVi. 

(27i, 272) h negedge E <J= 

member{{ V = Ni), 27i), member{{ V = N2), E2), N2 < Ni. 

Note that the variable E must have an actual value in 27i and E 2 , and it must have 
changed suitably, for an event to be deemed to have occurred. 
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An event involving a variable is either a positive or negative edge on that variable: 

{Si,S 2 ) h ^ 

variable(V), (Si, S2} \= posedge V or negedge V. 

Events may involve the disjunction of several events on single variables: 

{Si,U2) \= Event or -Event <= {Ei,E2) |= Event. 

{^1,^2) ^ -Event or Event <t= (I 7 i, 272 ) \= Event. 

Variables consist of simple Prolog atoms (functors without parameters). However, cer- 
tain reserved values and integer values should be avoided: 

reserved{tr\ie) . 
resert;e(i(false). 
reserved(e). 
reserved{()). 

variable{V) <;= atom( V), -iresert;ed( V), ->integer( V). 

If the standard member{. . .) clause is not available, it may be encoded as follows: 

member {X , {X \ —L)). 

member{X,{-X \ L)) <t= member{X , L). 

Finally, overriding of a variable’s value is required for Verilog’s procedural assignment: 

override{{ V = N), (), (( V = N))). 

override({V = N),{{V = -N) \ S),{{V = N) \ S}). 

override{{V = N), {{Vi = Ni) \ Si), {{Vi = Ni) \ S2)) <J= 

~'Vi= V , override{{V = N), Si, 52)- 

This concludes the support clauses needed for the semantics to allow the Prolog 
simulator to execute the transitions in a useful manner. These additional clauses also 
formalize and clarify the exact meaning of some aspects of the semantics that are left 
informal in the original mathematical formulation [ 20 ] . 

In execution, the top-level parallel transitions (both timed and untimed) are repea- 
tedly applied to the system state from a desired initial program and state. Execution 
concludes successfully if and when the program reduces to a parallel set of e sub- 
programs. The clauses are ordered carefully to return more “desirable” executions first, 
but the simulator will attempt to return alternative execution paths if these are possible 
according to the transition rules. Some example execution runs for simple programs are 
included in the next section. 

3 Animation of the Semantics 



We present a couple of example simulation runs of some simple Verilog programs using 
the operational semantics simulator partially presented in the last section. In normal 
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operation, Prolog will return possible answers to queries, in the order that they are found 
using its depth-hrst left to right search of the clauses. If an answer is found, the user has 
the option to request another answer or abort the search. If no answer can be found, the 
Prolog system simply responds with “No” and expects a fresh query from the user in 
response to its ?— prompt. 

The simulation includes additional support clauses to aid in the running of Verilog 
programs. Rather than continuously prompting the user, possible transitions are simply 
output to the display, using Prolog’s built-in write(. . .) pseudo-clause. The simulator 
continues until all the possibilities are exhausted or a set number of time steps or tran- 
sitions has been reached, in order to allow non-terminating programs to be aborted 
conveniently (using Prolog’s built-in abort clause). 



?- 


- run 


#3. 




0 




(# 3 , 0 , 0 , 


0 ) 


1 


X 

CO 


(^, 0 , 0 , 0 ) 




1 




(# 1 , 0 , 0 , 


0 ) 


2 




(^, 0 , 0 , 0 ) 




1 




(# 2 , 0 , 0 , 


0 ) 


2 




(^, 0 , 0 , 0 ) 




2 




(# 1 , 0 , 0 , 


0 ) 


3 




(^, 0 , 0 , 0 ) 




No 







Fig. 1. A delay of 3 time units. 



Consider a delay statement, allowing a delay of 3 time units (e.g., clock cycles), 
as shown in Figure 1 . The most “preferable” execution is to simply allow time to progress 
by 3 time units and then finish executing the program. However there are three other 
possibilities. Either time could progress by 2 units followed by 1 unit, or it could progress 
by 1 unit followed by 2 units, or it could progress by 1 unit in three steps. This program 
can proceed to termination in four different ways, as can be seen by the four occurrences 
of “e” above. 

Of course this non-determinism is not very interesting in the case of a single se- 
quential program, but consider three parallel assignments, each delayed by a different 
amount (see Figure 2). The simulator attempts to progress time by the maximal possible 
amount and executes the assignments after the required delays. The non-determinism in 
the delay construct rule allows this to be done in a natural way, letting the Prolog system 
explore the possible paths for us, and resolving the non-determinism in the process. In 
this particular case there is only one possible execution path since the difference between 
the delays is only 1 time unit, the minimum allowable time delay. 

Further examples of simulations can be found in [2,5]. The animation of such pro- 
grams allows the semantics of Verilog to be explored in a simple manner, with the extra 
conhdence that machine execution of a program brings compared to hand execution 
(e.g., as done in [20]). Once formulated, it is easy to add and remove rules to and from 
the Prolog simulator, and to modify them, to explore the consequences. 
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?- run #3 ; a = 1 || #1 ; 6 = 2 || #2 ; c = 3. 

0 (#3; a = 111 #1; 6 = 2 II #2; c = 3,(),{},0) 

1 -(IH (#2; a = 111 6 = 2 II #1; c = 3,(),(),0} 

2 ^ (#2; a = l||e||#l; c = 3,(6 = 2},{},2) 

3 ^ (#2; o = l||c||#l; c = 3,(6 = 2),(),0) 

4 -(IH (#1; a = l||c|| c = 3. (6 = 2), 0,0) 

5 ^ (#1; o = l||c||e,(6 = 2,c = 3),(6 = 2},3) 

6 ^ (#1 ; a = 1 II e|| e,(6 = 2,c = 3),(6 = 2},0) 

7 ^ (#1 ; a= 1 II e|| e,(6 = 2,c = 3),0.0) 

8 -(1)^ (a = l||£||e,(6 = 2,c = 3),0.0) 

9 ^ (e|| e|| e,(6 = 2,c = 3,a = l),(6 = 2,c = 3),l) 

10 ^ (e|| e|| e,(6 = 2,c = 3,a = l),(6 = 2,c = 3),0) 

11 ^ (e|| £|| e,(6 = 2,c = 3.a = l),0,0) 

No 

Fig. 2. Three parallel delayed assignments. 



4 Conclusion 



This exercise is considered a success in that the original operational semantics [20] has 
been very directly encoded in Prolog in a short period of time. Of course the rapid- 
prototype system produced is only suitable for very small Verilog programs, but it could 
be a useful didactic aid in the understanding of the semantics of Verilog programs which 
is otherwise only generally available in large informal documents such as the IEEE 
Standard [26] and textbooks [14] or in large software simulators that are necessarily 
deterministic for efficiency reasons. Alternatively, if the resources and demand were 
available, a much more robust simulator could be produced, based on the experience 
gained using this rapid-prototype. 

Of course, the simulator presented here does not cover the whole of Verilog. In par- 
ticular, modularization facilities are omitted, and these are important in larger Verilog 
programs. However, if further program constructs are considered worthwhile for inclu- 
sion, their operational semantics transition rules can be formulated and added to the 
simulator relatively easily. 

Despite the constraint of executability, the Prolog simulator operational semantics 
for a subset of the Verilog Hardware Description Language (HDL) developed and par- 
tially presented here is pleasingly close to the original operation semantics on which it 
was based [2,20]. Much of the development time was spent on establishing the correct 
precedence and associativity of the operators and then ensuring the ordering of the en- 
coded relations resulted in a preferred possible execution path being presented to the 
user first. 

An advantage of the logic programming approach, over the functional programming 
approach for instance, is that different execution paths can be allowed in a natural and 
implicit manner. This is especially useful in the execution of parallel programs (as nor- 
mally required in the simulation of physically parallel hardware) since the combinations 
of potential execution paths can be explored in a convenient way by the search and back- 
tracking facilities built into the Prolog system itself, with little or no explicit encoding 
for non-deterministic aspects required. 
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The execution time for the simple examples shown here is essentially instantaneous, 
so the simulator is very usable for didactic examples. Of course the presence of non- 
determinism means that the full search space is potentially exponential, so returning all 
possible execution paths for larger examples could be unacceptably slow. In addition, 
the amount of information displayed to the user could be overwhelming. However, with 
careful ordering of the clauses, the more interesting of the possible execution paths 
can be returned first. If just a single execution path is required, the simulator could be 
made acceptably efficient for much larger examples. For longer traces, it would also be 
sensible to only display important state changes (for example, between executions of 
instantaneous sections). This facility could be easily added to the simulator presented 
here. 

The architecture of the Prolog program modelling the operational semantics plays 
a vital role in its potential reusability. A two-level semantics for parallel threads and 
sequential programs (instantaneous sections) has been developed, and the success of 
the model demonstrates its overall compositionality [5]. It could be further enhanced 
by adding another level for open components, which could then help act as the basis 
for bisimulation and algebraic laws. Indeed, an interesting area for further exploration 
is the algebraic laws associated with Verilog [21]. The parallel aspects of Verilog mean 
that some laws associated with traditional sequential languages only apply in certain 
circumstances and additional laws are required for the parallel parts of the language. 
Using these laws, a compiler (written in Prolog, for example) from high-level Verilog 
programs to low-level digital hardware circuits could be produced. 

Hardware compilation (and its verification) of a high-level executable description 
specifying the desired function of the system to a low-level description of the mat- 
ching implementation components and their interconnections is an increasingly impor- 
tant technique in the production of digital hardware [4]. Ultimately, formalization of 
hardware/software co-design to help achieve a unified framework for computer system 
development is a goal worth pursuing [ 1 8, 19] . It is possible to use a parallel programming 
language such as Occam in a unified manner for this purpose [27]. However, although 
attractive formally, unfortunately it is unlikely to be widely used in practice since Occam 
is not popular in industry. 

Combining notations effectively and efficiently, be they informal, mathematical, 
non-executable or executable, is a way of adding extra assurance in the development 
of high-integrity systems by providing complementary ways of avoiding and removing 
errors [7]. It is a practice to be recommended in the industrial application of formal 
methods where failure could be costly in financial or even human terms [3,22]. 
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Of course, to say that nobody uses formal methods is an exaggeration, see 
the recent study by Dan Craigen: ’’Formal Methods Adoption: What’s Working? 
What’s Not!” (ORA Canada). Still, many things can be improved by adapting 
formal methods to the needs of its users (and not of researchers). This abstract 
highlights some aspects that we found important in our work with system desi- 
gners within Microsoft. 

Specifications should be easy to understand. The main purpose of writing spe- 
cifications is to gain understanding about the problem domain and to come up 
with appropriate models. Whether this understanding is correct typically can 
not be checked by formal means at all. Only conceptual and experimental justi- 
fication is possible. That’s why readability and - to less degree - executability 
is so important. 

Specifications should be state oriented. Specifications have to deal with exi- 
sting or proposed systems. And these systems - ranging from device drivers to 
Web applications - are typically state based. To “ignore” state does not help in 
developing reasonable, understandable models of these systems. This does not 
imply that particular logics are useless. Temporal logic, for example, is reason- 
able to specify liveness properties of state based systems. 

Specifications should support abstraction, subtyping and modularization. To- 
day systems are getting larger. They are getting more complex. Abstraction, 
subtyping and packaging play the central role in understanding these huge sy- 
stems. Abstraction helps to ignore irrelevant detail. Subtyping helps to define 
similarities. Modularization helps to build manageable self-contained units. Alt- 
hough these features are exactly in the domain of formal methods, it seems as 
if formal methods have not contributed to design or build huge systems at all. 
Systems practicioners often raise the question: Do formal methods scale? 

Specifications must live. We all believe in the value of specifications, but what 
happens when coding starts? Most code is not derived by any formal means from 
the specification. As a consequence, the specification very often becomes outda- 
ted and in most cases immediately looses its value. But even if we update the 
specification, how do we guarantee that the code behaves as described. There is 
only one answer: tools have to check that the specification and the implemen- 
tation aggree. One way to achive this is to instrument the implementation with 
assertions derived from the model. Another might be to generate test cases from 
the model. And there are various other routes. 

Specifications must be supported by tools. Current development practice is 
difficult to change. The only way to do it is to write tools with a high payoff. 
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The payoff can come in various forms: testing the design before implementing it, 
analysing the specification for properties like freedom from deadlock, etc. But 
it is simply not enough to have a notation and a process. Only when industrial 
strength tools are available, we are going to have a chance to influence the 
development process, too. 

Specification tools must be compatible and interoperable. Nowadays, most sy- 
stems are assembled from existing components rather than built from scratch. 
Specification methods and tools must be interoperable with existing environ- 
ments. Emerging standards like COM, CORBA or the new .NET platform of 
Microsoft can help to integrate specifications into existing systems. 

Specification tools must be easily portable and available. Many formal systems 
often only work in one environment, and very often this is Unix. Yet, companies 
typically do not choose their hardware based on the software tool they want to 
use. Simply porting tools is often not enough - modern tools should be integra- 
ted into the development environment. Specification documents should live in 
Word or HTML instead of TgX, specification sources should live in programming 
environments like Visual Studio, instead of just being command line applications. 

Specification building must be taught. Building the right model for non-trival 
systems is a challenging task. It takes a while to find the right abstractions 
and packaging. However it pays off. Experience shows that a week of training 
is needed to get started to write reasonable specifications. If you work for a 
company, maybe you can convince your company to go this way too? 
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Abstract. This paper presents a technique called generic composition 
to provide a neat basis for different kinds of semantic compositions and 
various higher-order healthiness conditions appearing in a variety of se- 
mantic theories. The weak inverse of generic composition is defined. A 
completeness theorem shows that any predicate can be written in terms 
of generic composition and its weak inverse, and a nnmber of algebraic 
laws are given to support reasoning. 



1 Introduction 

The modeling of programs as predicates coupled with the view of observation- 
oriented semantics simplifies the semantic interface, benefits from the expressive 
power of set theory and logic, and allows refinement to be expressed as im- 
plication. The use of predicate calculus is especially useful since variable hiding 
becomes as simple as existential quantifier applied to a predicate’s corresponding 
input and output variables. 

Such predicate semantics corresponds directly to relational semantics [9,10,14] 
and has been shown to span sequential (imperative, logic and functional) and 
parallel (synchronous and asynchronous) programming paradigms. This paper 
helps unify those various applications of the theory by proposing a form of com- 
position which unifies the forms of composition basic to those various paradigms. 

In [14] a semantic model is a set of predicates satisfying some healthiness 
conditions. The semantic model Pred without any healthiness condition is a 
complete lattice, which contains all predicates. Its top and bottom are predi- 
cate constants ‘false’ and ‘true’ respectively. Its lub (least upper bound) and gib 
(greatest lower bound) are conjunction and disjunction respectively. The orde- 
ring relation is refinement ordering C, such that A B if and only ii B ^ A 
is always true. 

The notion of ‘healthiness condition’ was first introduced by Dijkstra in [7] 
for predicate-transformer semantics. In [14] a healthiness condition is written 
h{-) where ft. is a higher-order predicate. A predicate A is healthy with respect 
to this healthiness condition, if h{A) is always true. A semantic model may 
satisfy several healthiness conditions. A model with more healthiness conditions 
is a subspace of a model with less ones. Let S be a semantic model. Imposing an 
additional healthiness condition ft(-) on S generates a subset model T A {A G 
S I ft(A)}. Any subset model preserves the refinement ordering as its ordering 
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relation; however top, bottom, lub and gib of a subset model may differ from 
those of the original model. 

If a healthiness condition h{A) can be expressed as an algebraic equation 
A = f{A), f is then called a healthiness function. If it is also idempotent i.e. 
/ o / = /, any unhealthy predicate X will be mapped to a healthy one f{X). 
A healthy predicate becomes exactly a fixed point of the function /. 

If all healthiness conditions are written algebraically A = f{A) and the cor- 
responding healthiness functions are idempotent and commute with each other, 
the composition of those functions is again a monotonic and idempotent fun- 
ction called a grand healthiness function in which the order of the healthiness 
functions can be arbitrary. 

Writing healthiness conditions in such a restricted way has following advan- 
tages: 

1. such a healthiness function characterises a link between semantic models by 
transforming each unhealthy predicate to a healthy one in the more detailed 
model; 

2. such a healthiness function maps a complete-lattice semantic model to a 
subset complete-lattice model; 

3. the semantic definition (also a function) of a command (e.g. sequential 
composition) is closed under a model iff the command commutes with all 
healthiness functions; 

4. according to a major theorem in [14] (Chapter 4), a healthiness function 
transforms the fixed point of a recursion program to that in a more detailed 
model if it satisfies a couple of simple conditions. 

These advantages suggest that we should write healthiness conditions in this 
form whenever it is possible. 

One would doubt whether this approach is general enough to cope with 
various healthiness conditions from very diversified semantic models. This is a 
reasonable concern, especially when those higher-order healthiness conditions 
are not as simple as conjunction A = AAH or disjunction A = Ay H. Suppose 
we have m healthiness conditions (in CSP [13] m = 8 and in BSP [21] m > 10) 
and n commands (in CSP n = 8, in BSP n = 13); then m x m proofs are 
needed for the idempotence and commutativity of the healthiness functions and 
m X n are needed for the closure of commands. Many technical proofs are not 
trivial. Furthermore a semantic space may not even be a complete lattice. The 
finitary condition (finite non-determinism) is an example. It seems that such a 
healthiness condition cannot be written in terms of a monotonic and idempotent 
healthiness function. 

In order to simplify the semantic studies on healthiness conditions, we pro- 
pose a new unifying technique called generic composition. By writing all healthin- 
ess functions with generic compositions, we can reduce the proofs of idempotence 
and commutativity to some easy-to-check conditions. Although some semantic 
models are not complete lattices, we find it convenient to add either top or 
bottom to the space to ‘forge’ a complete lattice (see Section 5). 
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The weak inverse of generic composition is also defined. A completeness theo- 
rem shows that any predicate can be written in terms of generic composition and 
its weak inverse, thus showing the technique is general. 

By using generic compositions, we have systematically defined (in terms of 
monotonic and idempotent fixed-point functions) higher-order healthiness con- 
ditions from a variety of models, such as Unifying Theories of Programming [14], 
CSP [11], CCS [15], Game Semantics [1], Z [22], probabilistic programming [8], 
safety and liveness properties [2] and BSP [18,5,6]. The technique has signifi- 
cantly simplified semantic studies on BSP [5]. 

[14] introduces a kind of parallel composition called parallel-by-merge. Its 
definition is based on sequential semantics. Two programs composed by a parallel 
composition are first simulated separately and their disjoint results are exported 
to a merge operation following them. However, as [18] noticed, the merge of 
BSP’s parallel composition may not be a valid merge (see [4,5]). Parallel-by- 
merge allows no interference between inputs in that its initial state is copied 
by both components. A Petri-net [20] counterexample in Section 5.1 shows that 
there can be ‘conflict’ between the inputs of the two components in a parallel 
composition. We propose a new kind of parallel composition called parallel-via- 
medium based on generic composition. It fixes BSP’s parallel composition [18] 
and leads to a more general parallel composition and simpler reasoning for it. 

Section 2 reviews the formalism from [14] required here. Section 3 intro- 
duces generic composition and its weak inverse. Section 4 introduces generic- 
composition-based sequential and parallel compositions and higher-order healthin- 
ess conditions. More advanced forms of generic compositions are also introduced 
in this section. Section 5 shows how generic composition can be used to define 
parallel compositions and higher-order healthiness conditions for various seman- 
tic models. 

2 Relational Semantics 

In this section, we shall review some formalism of [14] required in this paper. 

The fundamental concept in [14] is that of a binary relation. A binary relation 
is a pair (a, P) where a is a set of variables called the alphabet and P is a 
predicate containing no free variables other than those in a. We abbreviate that 
pair to P if omitting its alphabet does not lead to confusion. 

We may add a decoration to a to create a set of new variables. For example, 
a' is the set of dashed variables created from a' = {v' \ v € a}. Such a syntactic 
convention [22] is convenient for expressing different observable aspects of a 
program variable. For example, if a; is a program variable, x itself denotes the 
initial state of that program variable, while x' can denote its final state. We may 
also decorate a in other ways than by using dash: a, oq, cii, a.O, a.l, a. 2, 
etc. 

The alphabet a of a binary relation has two parts a™ and satisfying 
^in is & Set of undashed variables called the input alphabet, while 
is a set of dashed variables called the output alphabet. 
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For example, if x and y are the only program variables, the semantics of 
program a; := x + 1 becomes a relation 

{{x,y,x' ,y'}, x' = x+l^y' = y). 

The refinement order between two relations A and B with alphabet a is 
defined by A Q B = Va ■ {B ^ A) where a is a vector of all variables from a 
in an alphabetical order. Using alphabetically ordered variable vectors instead 
of variable sets is convenient for substitution. For example, A\(3q/(3] modifies 
A by substituting each variable x in /3 with another variable xq. Adding a 
decoration to (3 creates a vector of new variables in the same alphabetical order. 
For example, vector (3q has the same alphabetical order as /3. If x appears 
before y in /3, then variable Xq must appear before t/o in /3o- 

Sequential composition between two relations is then defined by 

A; B = 3q:o • A[a.o/a.'^^^] A B[a.o/a.in] 

where ccq is a vector of new variables (otherwise we use cki, 0 : 2 , etc.). 

Two special variables ok and ok' are introduced into the input and output 
alphabets respectively to represent termination/non-termination, ok represents 
the proper start of a computation, while ok' represents its successful termination. 

A design [14] is a binary relation satisfying A = {ok => A) and the downwards- 
closure healthiness condition of ok': A[false/ofc'] => A[true/o/c']. In general, a 
design can be written as b \- P where b is the weakest condition under which 
the computation terminates and P is a binary relation describing the constraints 
between the observable variables achieved on termination. Both b and P do not 
contain ok or ok' . 

A link between a semantic model S and its subset model T C S is a total 
function / : S — >■ S, which ranges over all members of T i.e. ran / = T. The subset 
model T satisfies not only all healthiness conditions of S but also an additional 
healthiness condition h{A) = A G ran /. 

The simplest form of parallelism that [14] (Chapter 7) tackles is called disjoint 
parallelism. If ok and ok' are the only free variables shared hy b\- P and c\~ Q, 
their parallel composition becomes b A c \~ P A Q. That means chaos (or non- 
termination) from either side will lead to a chaotic parallel composition; however 
if both sides terminate successfully, the parallel composition also terminates and 
achieves both P and Q in conjunction. 

Based on disjoint parallelism, a more general parallel composition called a 
parallel-by-merge can be defined [14]. In a parallel-by-merge composition, two 
components A and B are first simulated separately under disjoint alphabets by 
re-labeling. Then the results from both sides of the composition are combined 
and exported to a merge operation following them. 

Suppose m is the only program variable shared by two programs A and B. 
Their parallel composition is defined by 



A \\m B = {A[Q.m' /m'] || B\l.m' /m'])+rn ; M{ok^ m, O.m, l.m, m' , ok') 
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where merge M is a design, O.m' and l.m' are new dashed variables, and sub- 
script +m makes a copy of m: P+m = P /\ {m = m'). 

The following definition shows how complicated a healthiness condition can 
be. It is a healthiness condition for the trace record of CSP processes defined in 
[14]: 



A= A[s / tr ^ s {tr' — tr) / tr'\ 

R 

where ^ denotes concatenation between sequences. 

However the definition is not easy to understand. Actually it states that 
the behaviour of a reactive process does not depend on any behaviour before the 
start of this process. Its corresponding healthiness function is too complicated to 
allow straightforward proofs for its idempotence and commutativity with other 
healthiness functions. 



3 Generic Composition 

As motivation we observe that various compositional definitions and designs tend 
to have a similar pattern. For example, 

— in relational semantics [19], the sequential composition of two binary relati- 
ons r and s is defined by x {r; s) z = 3y ■ x r y A y s z ; 

— in CSP ([11] Section 4.3), the parallel composition between two communica- 
ting processes is defined by {{dv -A P)||(c?x — >■ Q{x))) \ C = {P\\Q{v)) \ C 
where communications along channel c are concealed; 

— in CCS ([15] Section 2.2), two components A and B with port c and c 
respectively can be combined and they communicate through the ports ac- 

cording to a rule ’ in which each communication becomes a silent 

a\bAa'\b' 

action not directly observable from the outside. 

In general, a system combining two components A and B demonstrates the 
behaviours of both A and B, and communications between the two components 
are normally delivered through an interface hidden from the outside. 

Generic composition provides a general form of such compositionality based 
on first-order logic. 



3.1 Definition 

A basic generic composition [6] is written as A B in which /3 is called interface, 
and A and B can be any predicates. A generic composition hides the interface 
between its components by applying an existential quantifier on the interface. 



Definition 1 A:p B = 3/3q ■ A[/3q// 3] A B[/3o//3]. 
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In this definition, we suppose /3 q is a vector of new variables free in neither A 
nor B and the interface (3 does not contain any overlined variable. The definition 
looks superficially like sequential composition. However it does not distinguish 
input and output variables; its interface is set explicitly; and there is no alpha- 
betical restriction. 

In this paper, we shall use A = 3xAto denote the condition that predicate 
A does not depend on variable x. For example, neither predicate {y > 2) depends 
on X, nor does {x = xAy > 2). In the latter example x is actually a free variable, 
although {x = X A y > 2) does not state anything interesting about x. Such 
variable independence is more general than syntactical restriction imposed by 
an alphabet ([14] Chapter 1). Interestingly A = \/x A states the same healthiness 
condition. 

Thus the alphabetical restriction can now be replaced by a series of healthin- 
ess conditions: 



A = 3xA {x ^ a). 

All these healthiness functions are idempotent and commutative, therefore they 
can be considered as a grand healthiness condition. Whenever we need an al- 
phabet for a predicate, we can simply impose this healthiness condition on it. 

The following propositions indicate some simple cases of basic generic com- 
position and are proved by routine predicate manipulations. 

Proposition 1 A A B = A -.(jf B . 

Proposition 2 3/3 A = A true. 

Proposition 3 A[ 7 // 3 ] = A\p (/3 = 7 ). 

3.2 Weak Inverse 

Most arithmetic operations have an inverse operation. For example — is the 
inverse of 3- in the sense that if x-|-p = g, we can restore x by calculating q — p. 

Not every operation has an inverse: sequential composition does not. In ge- 
neral X cannot be restored from X ; P = Q. Nevertheless it is possible to define 
sequential composition’s weak inverse Q/P, which is the weakest specification 
refining Q if followed by P 

Q/P= ^(Y;PAQ). 

This concept (Hoare and He [12]) is called the weakest prespecification. A weak 
inverse of parallel composition called weakest environment was defined by Lai 
and Sanders [17]. It was applied to Valiant’s BSP [21] by Lecomber [18]. 

A similar weak inverse operation can be defined for generic composition. We 
call it the weakest pre-predicate. Given two predicates Q and P, we define Q / pP 
to be the weakest predicate X making X :p P ^ Q always true. 

The following Galois connection provides a neat definition as a weak inverse 
in the sense of adjunctions. 



How to Write a Healthiness Condition 



305 



Definition 2 QQX -.p P iff Q/^P C X. 



Theorem 1 Q/f}P = ~^{^Q :fs P[(3 / (3 , [3 / [3]) . 

Now we can express some more primitive combinators; again the proofs are 
routine predicate manipulations. 

Proposition 4 A ^ B = 



Proposition 5 -•A = false/th 



Proposition 6 A\/ B = B / t]){false/ti) A). 



Proposition 7 V/3 A = A/ p true. 



Theorem 2 (Completeness) Any predicate can he written in terms of generic 
composition and its weak inverse using only the constant predicates true and 
false and predicate letters. 

This is justified by the fact that by Propositions 1 to 7 all logic operators of 
predicate calculus can be eliminated from the formula of a predicate. 

The completeness theorem shows the potential of generic composition for 
expressing and defining semantic operators, which we consider in section 4. 

3.3 Laws 

We shall use a convention x o y for disjoint sets: x o y = {x y = 0). Only 
non-trivial proofs are given. 

Law 1 (Associativity) {A B) C = A {B -.fs C) . 

Assume that a o /3, /3 o 7, 7 o a, A = 3'y A and C = 3a C, then 

Law 2 (Associativity') {A :„u /3 B) :/ 3 u 7 C = A -.aup {B C) . 

This law reveals some interesting precondition of general associativity. Law 1 is 
a special case of Law 2 when a = 7 = 0. 

Proof {A :„u/3 B) C _ 

= 3/3 i7i • (3oo/3o ■ {A[oLo/a,(3o/ (3] A B[ao/a,/3o//3])[/3i//3,7i/7 ] 
AC[/3i//3,7i/7]) 

= 3/3i7iao/3oy (-4[ao/a, /3 q// 3] A_B[/3i//3,7i/7][ao/a, /3 q// 3] 
AC[/3i//3,7i/7][ao/a,/3o//3]) _ 

= 3ao/3o ■ (-4[ao/a,/3o//3] A {B :^U7 C')[ao/a,/3o//3]) 

— A -aup {B C) 

□ 
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Law 3 (Distributivity of disjunction) 

{A\JB) ■.pC={A -.fs C)y{B C) 
A-.0 {BMC) = {A -.0 B)W{A -.0 C). 



Law 4 (New interface) A = A {(3 = (3) 

A=(^ = f3):p A. 

f3 = (3 is called the (3-identity predicate. It forms a left and right zero of 
generic composition. 

Law 5 (Conjunction elimination) 

A A {A '.fj B) = A {(3 = (3 A B) 

{A-.pB)AB=(0 = pAA) -.0B. 



Law 6 (Disjunction elimination) 

AV{A -.0 B) = Ajp (0 = I3VB) 

{A-.pB)\/B={(3 = (3\/A) :0B. 

Assume A = 3'y3^ A and B = 3'y3^ B, then 

Law 7 (Interface re-labeling) A:p B = A[7//3] B[^/[3]. 

The interface of a generic composition can be replaced by some new variables. 
Assume A = 37 A and B = 3^ B, then 

Law 8 (Interface expansion) A B = A B = A ■./ju.y B. 

Assume jo (3, then 

Law 9 (Interface extension) A -.p 3^ B = A (7 = 7 A 3j B) 

37 A B = (7 = 7 A 37 A) :^U7 B. 



Proof. A (7 = 7 A 37 B) _ 

= 3/3o7o ■ ^[/3o//3,7o/7] A (70 = 7 ) A 3jB[(3q/(3] 

= 3/3o ■ A[(3q/(3] a 3^B[(3q/0\ 

= A :p 37 B. 

The second part of this law can be proved similarly. □ 

Assume 70 / 3 , B = 3'y3f B and C = 3/33/3 C, then 

Law 10 (Left /right interface commutativity) 

(A \p B) '.ry C = A '.p\j~f {B A C) = (A C) :p B 
C {B :p A) = (C A B) A = B -p {C A). 
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This law describes a sufficient condition under which two interfaces (3 and 
7 will not interfere with each other, and therefore components B and C are 
actually placed in conjunction and can be connected to an existing component 
A in either order. Thus components B and C can be considered to be in parallel. 
Parallel-via-medium in Section 4 is defined on this law. 

Proof. (A -.jj B) -.j C 

= A :/3u7 = 1 :^U7 (/3 = /3 A C) 

= ^:/3U7 ((7 = 7AB) :7 C) 

= A :^U 7 {B A C) 

= {A C) -.0 B. 

The second part of this law can be proved similarly. □ 

Assume C = 3f33f3 C, then 

Law 11 (Commutativity with conjunction) 

{A:0B)AC = {AaC):0B = A:0{BA C). 

This is a special case of Law 10 when 7 = 0. If component C has no inter- 
ference with the interface of another generic composition in conjunction, it can 
be located anywhere in the composition. 

Assume A = 37 A, B = 37 B, C = 3(3 C and D = 3(3 D, then 

Law 12 (Interface merge) (A B) A {C :.y D) = (A A C) :0\j'y (BAD). 

If the interfaces of two generic compositions in a conjunction have no inter- 
ference with each other, they can be merged into a joint interface. 

Proof. 

1. If /3 o 7 , then 

(A -.0 B) A (C D) 

= ( 3^0 • A[/ 3 o// 3 ] a B[(3o/(3]) A (370 • ^[70/7] A ll[ 7 o/ 7 ]) 

= 3/3o37o ■ A[/3o//3] A B[(3q/(3] A C[ 7 o/ 7 ] A £>[70/7] 

= {AaC) :^ u 7 {bad). 

2. If / 3 ri 7 = ^y^0 and ip = (3\4>, then A -.0 B = A B according to Law 
8 . □ 

4 Defining Other Semantic Operators 

4.1 Sequential Composition 

A sequential computation is a predicate with input alphabet ain and output 
alphabet Oout- The input alphabet contains all observable program variables and 
the output alphabet contains all modifiable program variables. We suppose any 
modifiable program variable is also observable, i.e. Uout C ain. Then sequential 
composition can be defined on generic composition. 
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Definition 3 A; B = A B[cx'^^Joiout]- 

Interestingly, it is also possible to define it in the reverse order. Note that the a 
generic composition X \fj Y, any variable x:j3 vci X corresponds to x in Y. 

Theorem 3 A; B = B A[aout/a'^ut]- 

The sequential composition is a special kind of generic composition where 
the interface is set to be all output variables. Thus its properties can be easily 
deduced from the laws in section 3.3. 

4.2 Parallel Composition via Medium 

Parallel-via-medium composition is defined as follows: 

M 

Definition 4 A \\^B = (A[7r.0/7r] A S[7r.l/7r]) Itt.outt.i M. 

Variable set tt explicitly sets the interface between A and B. If components A 
and B do not depend on tt.O and tt.1, tt will be substituted by two vectors of 
new variables tt.O and tt.1 in A and B, respectively. In case Aor B depends on 
TT.O or 7T.I, law 7 can be used to re-label the interface with some new variables 
to avoid interference. 

M is called a medium between A and B. A medium puts all information 
from TT.O and tt.I together and restores interface tt. To make a parallel-via- 
medium composition commutative and associative, a medium needs to satisfy 
corresponding healthiness conditions. 

The convention 11^ = (W.z = tt) is used in the following theorems. Thus we 

M 

have M = Eq II We also assume that A, B and C do not depend on any 
variable in ttA or W.i (i = 0, 1, • • • ). 

M M 

Theorem 4 A \\ ^ B = B \\ ^ A, iff M is eommutative in this sense 

M M 

Eo IUIi=IIi lUIo. 

MM MM 

Theorem 5 {A \\^B) \\^C = A \\^{B \\^C), iff M is associative in this 
sense 

MM MM 

(lo lUIl) IUl2=IIo IU(Il IUI2). 

Proof. Let Ag = [tt.O/tt], Bg = [tt.I/tt] and Cg = [7r.2/7r]. If M is associative 
then 

M M 

KB) luc 

M M 

= (Ag A i?i :,r.0U7r.l lo Il,r 2 i) || „. C 

M M 

= (Ag A i?i) iTT.OUTT.l (Iq IItt^i) II (C'2 : 7 t .2 I2) 
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— A II ^ (-Bl A C 2 :7T.lU7r.2 Hi || 7 T^ 2 ) 

M M 

= ^ WAB lUC). 

The other direction of the theorem is proved by assigning A, B and C with Ig, 
Ii and E 2 , respectively. □ 

Parallel- via-medium has one more parameter tt. It may include either shared 
or unshared output variables, input variables or their mixture. However, if tt 
is the set of all shared output variables of both components, the composition 
becomes a parallel-by-merge composition [14]. 

4.3 Higher-Order Healthiness Conditions 

A higher-order healthiness condition defined on generic composition is normally 
written in the form A = A i? and called generic healthiness condition. Its 
corresponding healthiness function is XX ■ X '-is R. 

Writing a healthiness condition in this form is motivated by [14] (Chapter 
3) in which the condition H3 for the total-correctness of designs is defined by 
A = A ; II where II denotes the ‘skip’ command. Besides the simplicity of this 
condition, the proof of its idempotence is pleasingly straightforward E; II = E. As 
we discussed before in Section 1, the proofs of idempotence and commutativity 
can be otherwise extremely difficult for a real language [5]. This technique has 
provided a simple solution and a uniform way of writing and reasoning about 
higher-order healthiness conditions. 

Most healthiness conditions cannot be defined in this form with a sequen- 
tial composition. Fortunately, using generic composition, we can generalise this 
technique and tackle a variety of more complicated healthiness conditions (see 
Section 5). 

In a real semantics, there can be a mixture of conjunctive, disjunctive and 
generic healthiness conditions. The following theorems study the conditions un- 
der which a healthiness function based on generic composition is idempotent and 
commute with other healthiness functions. 

Theorem 6 AX ■ X \fj R is an idempotent function iff R '.p R = R. 

Theorem 7 If R = 3'y3ff R and S = 3/33/3 S', then XX ■ X R and XX ■ 

X :.y S commute. 
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Theorem 8 If S = 3/33/3 5, then XX ■ X -.p R and XX ■ X A S commute. 



Theorem 9 If S = S :p R, then XX ■ X -.p R and XX • X V 5 commute. 



Theorem 10 If S = S :p R, then XX ■ X -.p R and XX ■ X <\ 3/3 b [> S 
commute. 



In this definition, the binary conditional A<\h\>B is defined as {hAA)\/ {—hAB). 



4.4 Two-Dimensional Generic Composition 

A parallel-via-medium composition in which the components on both sides are 
identical becomes a more general kind of composition called a two-dimensional 
generic composition. 

B 

Definition 5 The construct A ::p B = A \\pA is called a two-dimensional 
generic composition. 

If we consider A as a component, a two-dimensional generic composition 
with another component B compares any two behaviours of A by allowing only 
some of the observable variables (i.e. in j3) to be different. 

This composition enjoys some laws (e.g. associativity) similar to those of 
basic generic composition in Section 3.3 and Section 4.3. 

A healthiness condition based on this composition is normally written in the 
form A = A ::p R. The significance is that the component A in the definition 
appears twice; thus it makes it possible to compare any two values of the variables 
in /3. 

This technique is highly useful when we need to impose a healthiness condi- 
tion on the range of some variable. A range is the set of the non-deterministic 
choices of a variable when other variables are fixed. For example, the range of y 
in predicate (y > a; -I- 1) is {n € IN | n > 5} if a; is fixed on 4. 

4.5 Multi-dimensional Generic Composition 

We take one further step to allow up-to-infinitely-many copies of a component to 
appear in a predicate. Note that the following definition may contain an infinite 
number of variables. 

Definition 6 A:pi B= (Aig/ A[f3.i/(3]) -[j.^^p.i B. 

In the definition, I is called an indexing set. Each index i in / corresponds to a 
copy of A whose variables in (3 are substituted by those in f3.i. This composition 
enjoys some laws similar to those in Section 3.3 and Section 4.3. 

If / = {0, 1}, this definition collapses to a two-dimensional generic composi- 
tion; however if I is an infinite set, interface {(3i \ i G 1} from the copies of A will 
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form a subset (cardinality up to that of I) of the all possible non-deterministic 
choices; if I is the Cartesian product of the types of the variables from f3, the 
interface can form any subset of the non-deterministic choices. 

A healthiness condition based on this composition is normally written in the 
form A = A \ pi R. The significance of this composition is that now we can 
impose healthiness restrictions on the cardinality or limit points of a variable’s 
range. 

5 Applications 

In this section we shall demonstrate the expressive power of generic composition 
by applying it to yield a variety of compositions and higher-order healthiness 
conditions. 

5.1 Parallel Compositions 

Conjunction. A (binary) parallel composition demonstrates the behaviour 
of two components at the same time and therefore becomes a conjunction if there 
is no interference between the two components. 

true 

Propositions A f\ B = A || gS. 

Interference between the inputs. In a parallel-by-merge composition, the 
merge is composed sequentially after the two components. That means the initial 
states X of the two components are simply the direct copies of the initial state of 
the parallel composition. No interference is allowed at the beginning of a parallel 
composition. 

However this may not be general enough in some cases. For example, in 
the following Petri net, a token in x can be received by either process A or 
process B. It is not compatible with parallel- by-merge in that the number of 
tokens received by process A (denoted by a;.0) directly depends on the number 
of tokens received by process B (denoted by i.l). 
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Fortunately we can define it as a parallel-via-medium composition with an 
interface containing both input and output variables. 

M 

Definition 7 A\\ B = A B where 

M = {x = x.O + xA) A (x' = x'.O + x'A). 



5.2 Healthiness Conditions Based on Basic Generic Composition 

In this section, we will study some healthiness conditions appearing in various 
semantic models. Each healthiness condition is written in the form A = A B, 
A = A ::j 3 B or A = A B. The corresponding monotonic and idempotent 
healthiness function transforms any unhealthy predicate to a healthy one. 

Recall that the range of a variable in a predicate is the set of all possible 
values of the variable when other variables are fixed. 



Downwards-closure. In semantic studies we often need to stipulate a va- 
riable X to be downwards-closed or upwards-closed. Let the type of variable x 
be real numbers. The following healthiness condition requires the range of x to 
be (—oo,a) or (— oo,a] where a can be any real number. 

Healthiness 1 A = A {x <x) . 

The ranges of x in the following healthy predicates can be simply compared by 
refinement ordering. For example {y + 1 > x) ^ {y + 1 > x) ^ {y + 2 > x) ^ 
(y+2 > x). According to Theorem 6, the healthiness function XX -X (x < x) 
is idempotent if (x < x) :[x} (x < x) = (x < x), which is obvious. Healthiness 1 
defines a more general downwards-closure if the type of a; is a partial ordering. 
Upwards-closure can be expressed by replacing < with >. 

Comparison of non-determinism. A similar healthiness condition states 
that the value of y is always a possible non-deterministic choice of x. 

Healthiness 2 A = A x G {x, y}. 



Prefix independence. The healthiness condition A = sA[s/tr, — 

tr)/tr'] for traces mentioned in section 2 now becomes as siJiilple as follows: 

Healthiness 3 A = A :^tr,tr'} {tf' — tr = tr' — tr). 

It is an easy exercise to check that the corresponding healthiness function is 
indeed monotonic and idempotent. 
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Healthy Designs. Another healthiness condition A[false/ofc'] => A[true/ofc'] 
for the designs mentioned in Section 2 is redefined: 

Healthiness 4 A = A ifok'} {ok' ok'). 

If the range of ok' in a predicate A is {false}, the generic composition will 
transform the predicate by adding ‘true’ to the range. Thus a predicate is healthy 
in this sense iff it is either deterministic on ‘true’ or non-deterministic between 
‘true’ and ‘false’. 



Prefix closure of strategy. In game semantics [1] a strategy S' is a non- 
empty set of even-length (2 | len{s)) sequences satisfying a few healthiness con- 
ditions. One of them is the prefix-closure condition: 

sab € S ^ s € S. 

The generic-composition way of writing this is: 

Healthiness 5 A = A (2 | len{s) A s <s). 

The corresponding healthiness function is monotonic and idempotent and it 
transforms any unhealthy predicate to a healthy one by adding all even-length 
prefixes of each sequence. 



5.3 Healthiness Conditions Based on Two-Dimensional Generic 
Composition 

Sometimes the component A needs to appear twice in /(A). In that case, two- 
dimensional generic composition is needed. 



Decoupled variables. For example, in distributed computing asynchronous 
communication exhibits latency. If there is no causal relation established by any 
communication between two observable variables, we call them decoupled varia- 
bles. The following healthiness condition states that, if x and y are decoupled 
variables, their non-deterministic choices are not directly correlated. That means 
the range of joint non-deterministic choices of the two variables is exactly the 
Cartesian product of their separate ranges. 

Healthiness 6 A = A -.{x.y} {x G {x.O, S.l} Ay G (y.O, y.l}). 

Let {x, y, z} be the set of all free variables of A. The above healthiness condition 
is satisfied iff A{x,z,y) can be decomposed into two predicates A\{x^z) and 
A 2 {z,y) in conjunction, i.e. A{x,z,y) = Ai{x,z) A A 2 {z,y) where x is not 
directly related to y. 



314 



Y. Chen 



Determinism. In relational semantics [19], a variable is deterministic if its 
range is always a singleton set. The semantic space of deterministic relations is 
not a complete lattice because the gib operator (i.e. relation union) is not closed 
in the space. However adding the bottom ‘true’ to such a space will create a 
complete lattice, which can be expressed as: 

Healthiness 7 A = A\/ A (aJ.O ^ xA). 

The corresponding healthiness function transforms any deterministic predicate 
to itself and any non-deterministic predicate to the bottom. Although this defini- 
tion has an equivalent form A = A {x G {x.O,xA}Vx.O ^ xA)^ Healthiness 
7 looks simpler. 

The range of x may be an empty set, a singleton set or the set of all possible 
values. Although it is not exactly a healthiness condition for pure determinism, 
their difference lies only at some ‘extreme’ points. This is a cheap price to pay, 
because what we obtain is a uniform way of writing its healthiness condition 
and the semantic space now becomes a complete lattice. This technique is called 
Completisation and has been our standard technique to deal with non-complete- 
lattice semantic models [5]. 



Deterministic strategies. In game semantics [1], a player and its opponent 
act alternatively in a play. The player may play deterministically according to 
the pre-history: if both sab and sac are healthy (even-length) sequences of a 
strategy, they must be identical, i.e. b = c. This healthiness condition is defined 
as follows: 

Healthiness 8 A = A V A 3tabc (s.O = tab A s.l = tac Ab ^ c). 

The corresponding healthiness function transforms any deterministic strategy 
to itself and any non-deterministic one to the bottom predicate ‘true’. The In- 
nocence condition in game semantics [1] is very similar to Healthiness 8. Other 
healthiness conditions in [1] including bracketing condition can be trivially defi- 
ned as conjunctive conditions. 



Convexity of probabilistic distributions. In probabilistic semantics [8], 
the value of a variable / is a probabilistic distribution function f :W -A [0, 1] 
where W is the set of all states. The following healthiness condition states that 
the distributions of variable / form a convex area in the space containing all 
possible distribution functions. 

Healthiness 9 A = A ::yy (3A: [0, 1] • (/ = A * /.O -I- (1 — A) + /.!)). 

The corresponding healthiness function transforms a predicate by adding inter- 
mediate linear combinations of every two distributions into the range. 
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5.4 Healthiness Conditions Based on Infinite-Dimensional Generic 
Composition 

If infinitely many copies of component A are allowed to appear in a healthiness 
condition, we will be able to reason about the cardinality of a range and the 
limit points (also called ‘cluster points’) in a range. 



Closed sets and safety properties. Let the type of variable a; be X where 
(X, T) is a topological space. The following healthiness condition requires that 
the range of the variable is always a closed set. 

Healthiness 10 A = A (x S closureif^). 

where = {x.i | i G X}. 

There are as many as cardinal X copies of A’s appearing in this definition. 
Thus can be any non-empty subset of x’s range. The corresponding healthin- 
ess function of this condition transforms any predicate with not closed range to 
a predicate with the smallest closed range containing the original range. 

In the semantic models based on temporal logic (e.g. TLA [16] and UNITY 
[3]), a reactive process is an infinite sequence of states, each of which has a type 
T and hence the space of all processes is X = T“. There is a natural topology 
on X in which each basic open set is the set of all infinite sequences sharing a 
common prefix and each open set is the union of some basic open sets. It has 
been proved [2] that safety properties are exactly the closed sets of the topology, 
(pure) liveness properties are exactly the dense sets, and any property can be 
expressed as the intersection of a safety property and a liveness property. 

Thus the set of all predicates satisfying Healthiness 10 on a sequence variable 
X forms a semantic space for all safety properties. The corresponding healthiness 
function transforms any property to the strongest safety property implied by it. 

Dense sets and liveness properties. A dense set intersects every non- 
empty open set. The following healthiness condition requires the range of variable 
X to be a dense set: 

Healthiness 11 A = A f\ A VO : T • (0 o =>0 = 0) 

There are as many as cardinalA number of copies of A appearing in the de- 
finition. The corresponding healthiness function (monotonic and idempotent) 
transforms any predicate with a dense range to itself and unhealthy predicate 
to the top ‘false’. Again we need the help of one extra point ‘false’ to make the 
space to become a complete lattice, because the intersection of dense sets may 
not be dense. 

Another interesting way to write a healthiness condition for liveness is: 

A = A X ^ (closureA^ - Uj) 
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Its corresponding healthiness function together with that of Healthiness 10 de- 
composes any property into a pair of safety and liveness properties in conjunc- 
tion. Although this function is idempotent, it is not monotonic and the corre- 
sponding semantic space is not a complete lattice. 

Cauchy-closure of probabilistic distributions. Healthiness 9 requires the 
range of a variable to be a convex area. However the boundary points (i.e. limit 
points) may or may not be included in the range. The Cauchy-closure healthiness 
condition in [8] requires those boundary points to be included. To reason about 
limit points, we need an infinite-dimensional generic composition. Recall that the 
type of a variable / is a set of total functions .7^ = VF — >■ [0, 1] (i.e. probabilistic 
distribution). If IF is a finite set, T is isomorphic to a n-dimensional Euclidean 
space where n is the cardinality of W . Cauchy-closure is then defined by: 

Healthiness 12 A = A (Ve > 03i • \ f.i — /| < e) 

In the definition, | • | is a Euclidean distance measure associated with the Euc- 
lidean space. The corresponding healthiness function transforms any predicate 
by ‘pasting’ those boundary points to the range of variable /. 

If the state space is the set of real numbers (i.e. W = IR) and any / : iF is inte- 

grable and f{t)dt< 1, the distance is defined by |/| = ^ 
and Healthiness 12 is still applicable. 

Finitary condition of relations. Another important healthiness condition 
of relational semantics [19] is called the finitary condition, which corresponds to 
the V-continuity condition of predicate-transformer semantics [7]. A variable is 
finitary if its range is either a finite set or the set of all possible values. 

Healthiness 13 A = A\J (cardinali7,^ = w). 

There are up-to-w number of the copies of A appearing in the definition where 
u) is the cardinality of IN. Its corresponding healthiness function transforms a 
non-finitary predicate by pasting all other possible values to the range of x. 

6 Conclusions and Acknowledgement 

Our objective is to aid semantic studies on real programming languages. The 
introduction of generic composition serves this purpose by unifying various se- 
mantic definitions. The definition of parallel composition and the presentation 
of its associativity become more general and simpler than parallel-by-merge. 
The technique also provides a unified form for defining healthiness conditions. 
The completeness theorem shows the evidence of its generality in theory. The 
examples from a variety of theories have shown its generality in practice. 

This paper is part of the author’s D.Phil thesis. The author would like to 
thank his supervisor J. W. Sanders for the discussions and encouragement and 
the anonymous referees for their helpful comments. 
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Abstract. The aim of this paper is the introduction of preemption in 
a compositional model, called M-nets, which is based on Petri nets and 
hence provided with a concurrent semantics. We propose a way to mo- 
del preemptible systems by extending the M-net model with priorities 
and the M-net algebra with a preemption operator. We show that these 
extensions can be seen as a high-level version of the well studied model 
of priority systems, and so, can be reduced to Petri nets (without priori- 
ties) which retain as much as possible of the original concurrency. As a 
consequence, Petri nets appear as a model powerful enough to deal with 
preemption in a compositional way and with a concurrent semantics. 

Keywords. Petri nets. Preemption, Goncurrency, Gompositionality. 



1 Introduction 

Preemption relates to controlling the execution of the processes composing a 
concurrent system. Such processes are said preemptible if they can be suspended 
at any point of their execution. 

Preemption is often addressed in reactive systems, for instance in synchronous 
models and languages [14,1]; for some of them, it is even an essential feature. 
In most cases, the underlying semantics is sequential, which is well suited to the 
modeling of systems in which the computation performed in response to an input 
coming from the environment is relatively simple. But when the structure of the 
computation becomes more important than the structure of the reaction, the se- 
quential semantics may be not sufficient. A concurrent semantics is often more 
adapted to the modeling of heterogeneous architectures which combine software 
(distributed on several processors) and specialized hardware components. In par- 
ticular, playing with the scheduling of operations often allows a better resource 
management. 

Petri nets form an inherently asynchronous model in which concurrency can 
be represented explicitly. This model and some of its extensions [22,23] have been 
used for works on preemption, but in an unstructured way (non compositional). 

This paper addresses the question of preemption in the context of composi- 
tional Petri nets. This naturally leads to consider the framework defined by the 
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Petri Box Calculus (PBC [3,2]). The proposed approach tends to be as conserva- 
tive as possible with respect to the existing framework, with the goal to minimize 
the changes necessary in order to adapt the existing tools to the proposed model. 

PBC is a process algebra with a syntactic domain of box-expressions and 
a corresponding semantic domain of boxes, a class of labelled 1-safe Petri nets 
provided with an algebraic structure. It has been introduced with the aim of 
modeling the semantics of concurrent systems and programming languages. In 
order to cope with the possibly huge size of the nets, higher level versions of PBC 
have been considered, and in particular an algebra of M-expressions (high-level 
equivalent of box-expressions [18,16]) and M-nets (high-level Petri net version 
of boxes [4]) which allow to represent large (possibly infinite) systems in a clear 
and compact way. The high- and low-level domains are related by an operation 
of unfolding which associates a box-expression to each M-expression and a box 
to each M-net. 

The PBC framework also features a parallel programming language, B(PNp 
[5], which can be seen as a “user friendly” syntax on the top of both, high- 
and low-level process algebras. It is implemented in PEP toolkit [13], allowing 
to simulate modeled systems and to verify their properties via model checking. 
Several contributions [5,4,20,12,19,15] provide applications to the PBC theory 
where box-expressions, M-nets and M-expressions are used as the semantical 
domain for B(PN)^. 

In this paper, the M-net model is extended by considering priority M-nets 
as pairs (iV, p) where N is an M-net and p a pairwise priority relation between 
its transitions. The M-net algebra is then enriched by a new operation, tt, which 
allows to make preemptible any priority M-net and can be nested arbitrarily. 

We are particularly interested in a sub-class of priority M-nets, called pre- 
emptible M-nets {P /M-nets), which fulfill some structural constraints. We show 
that the concurrent (step) semantics of P/M-nets is sound with respect to the 
semantics of preemption. 

Moreover, applying results obtained in some related areas, we show for a 
large class of P/M-nets, that they can be transformed into 1-safe Petri nets 
(without priorities), retaining as much as possible of the concurrent semantics. 
The transformation leads to really huge nets which cannot be used in practice, 
nevertheless, this means that 1-safe Petri nets are expressive enough to model 
preemption in a compositional framework. 

The rest of the paper is organized as follows. Section 2 gives some intuition 
about the aspects of M-nets which are important for our purpose. Section 3 
discusses preemption and the impact of its introduction in the context of Petri 
nets. Section 4 introduces priority M-nets, defines operation tt, and extends 
the usual M-net operations to such nets. Then, P/M-nets are introduced as a 
structurally restricted class of priority M-nets, and their concurrent semantics is 
shown sound with respect to the semantics of preemption. A detailed example 
with nested P/M-nets is given in section 5. Section 6 discusses some properties 
of P/M-nets and, in particular, their transformation to 1-safe Petri nets. The 
paper ends with some concluding remarks. 
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2 M-Net Model 

2.1 Basic Definitions 

Let E he a, set. A multi-set over is a function /j, : if — ?► N, generally denoted 
with an extended set notation, e.g., {a, a, 6} for ^(a) = 2, /r(6) = 1 and /i(e) = 0 
for all e G if \ {a, h}. /r is finite if so is its support set E \ /r“^(0). We denote 
by M{E) (resp. Mf{E)) the set of multi-sets (resp. finite multi-sets) over E, by 
0 and 0 the sum and difference of multi-sets. We may also use the usual sets 
notations such as C or G; for instance, e G /r stands for /x(e) > 0. 

2.2 M-Nets 

M-nets [4] form a class of high-level Petri nets provided with a set of operations 
giving them a structure of process algebra. We use here the M-net model defined 
in [8], and its asynchronous links extension from [17]. 

An M-net N is a triple {S, T, (.), where S is the set of places, T is the set of 
transitions, (T x S') U (S' x T) is the set of arcs, and t is the annotation function 
on places, transitions and arcs. The annotation of a place is of the form A.t, 
where A is a label (entry e, exit x or internal i) and r is a type (a non-empty 
set of values from a fixed set Val). As usual, for each node (place or transition) 
r G S U T, we denote by *r the set of nodes |r' G S U T | t(r',r) yf 0} and, 
similarly, r* = {r' G S U T | i(r, r') yf 0}. 

Transitions annotations are of the form A. 7 where A is a label (which can be 
hierarchical or for communications) and 7 is a guard (a finite set of predicates 
from a set Pr). Hierarchical labels are composed out of a single hierarchical 
action {e.g., X') indicating a future refinement (i.e., a substitution) by an M-net. 
Communications may be: 

— synchronous, similar to CCS ones [21], e.g., between transitions labelled by 
synchronous communication actions such as A{ai, . . . , an) or A{a'^, . . . , a'^), 
where A is a synchronous communication symbol, A is its conjugate and each 
ai and a( is a value or a variable (belonging to a fixed set Var) ; 

— asynchronous, e.g., between transitions labelled by asynchronous links such 
as 6“*"(ai) or 6“ (02), where b is an asynchronous communication symbol and 
each Oi is a value or a variable (ranging in typeib) C Val). The communication 
is done via a place Sh of type r(s;,) = type{b) which plays the role of a heap 
buffer. Link 6“''(ai) means that a\ can be sent to sj, and b~{a2) means that 
tt2 can be received from Sf,; 

— or possibly both at the same time. 

Communication labels are then of the form A = a.p where a is a finite 
multi-set of synchronous communication actions and /3 is a finite multi-set of 
asynchronous links. 

Arcs are inscribed by multi-sets of structured annotations representing multi- 
sets of values consumed or produced by a transition in a place. Structured an- 
notations are variables, values or more complex structures allowing to cope with 
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place types generated by refinements [8,10]. As usual, in figures, arcs with an 
empty annotation will be omitted; moreover, annotation {•} on an arc is omitted 
most of time and singletons are often replaced by their unique element. 



2.3 Dynamic Behavior and Concurrent Semantics 

For each transition t € T we shall denote by var{t) the set of all the variables 
occurring in the annotations of t and in the arcs coming to and from t. A binding 
for a transition t is a substitution cr : var(t) — > Val] it will be said enabling if it 
satisfies the guard, if it respects the types of the asynchronous links, and if the 
flow of tokens it implies respects the types of the places adjacent to t. 

A marking of an M-net (S,T,l) is a mapping M:S^ M.{Val) which asso- 
ciates to each place s & S a, multi-set of values from r(s). In particular, we shall 
distinguish the entry marking, denoted Me, where, for each s £ S, Me(s) = r(s) 
if A(s) = e and the empty multi-set otherwise; the exit marking is defined simi- 
larly. The dynamic behavior of an M-net starts with its entry marking; it ends 
(if ever) with the exit marking. 

The transition rule specifies the circumstances under which a marking M' 
is reachable from a marking M. A transition t is enabled at a marking M (this 
is denoted M[t)) if there is an enabling binding a of t such that \/s £ S : 
t(s,f)[cr] C M{s), he., there are enough tokens of each type to satisfy the required 
flow. The effect of an occurrence of t is to remove from its input places all the 
tokens used for the enabling binding cr and to add to its output places the 
tokens according to a; this leads to a marking M' such that Vs £ S: M'{s) = 
M(s) 0 t(s,t)[cr] 0 i{t, s)[cr]. 

The above transition rule defines the interleaving semantics of an M-net 
which consists in a set of occurrence sequences. This semantics can be generalized 
by introducing the step sequence semantics [9], which allows any number of 
transitions to occur simultaneously. 

Given an M-net N = {S,T, l), a multi-set S of transitions is said concurrently 
enabled at a marking M if there are enough tokens to allow the simultaneous 
firing of all the transitions in 5. Such a i5 is called a step. A step sequence of N 
is a sequence D = (<5i, 82 , ■ ■ ■) such that there are markings Mi, M 2 , . . ., where 
Ml = Me and which satisfy Mi[5i)Mi+i for i > 1. The set of step sequences of 
N is its step sequence semantics and is denoted by steps{N). It is easy to see 
that steps{N) is stable under linearisation: if S belongs to a step sequence D in 
steps{N), then, replacing S with any of its linearisation gives a step sequence 
which is also in steps{N) {e.g., {^ 1 ,^ 2 } can be replaced by {ti}{t 2 } or {t 2 }{ti}). 



2.4 Unfolding 

Let N = (S,T,l) be an M-net. The unfolding of N is the labelled Petri net 
U{N) = {U{S),U{T),W,\), where U{S) is the set of places, U{T) the set of 
transitions, W the weight function on arcs and A the labelling function on places 
and transitions, defined as follows: 
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W(/S') = {(s, z;) I s € S' and G r(s)}, and V(s, i>) € W(S') : A((s, ?;)) = A(s); 
U{T) = {{t, a) I t G T and a is an enabling binding of t}, 
and V(t, a) G U{T) : 

a(t)[a\.( 3 (t)[a\ if f is a communication transition, 

\(t) if t is a hierarchical transition; 

W{{s,v),{t,a)) = ■ x[a]{v), where x[a]{v) is the number 

x^i{s,t) 



A((t,cr)) = 



of values v occurring in the structured annotation x evaluated under <t; 
W{{t,(T),{s,v)) is defined analogously. 



If M is a marking of N, the marking U{M) of U{N) is defined as follows: 
for every place (s,t>) G U{S), U{M){{s,v)) = M{s){v), i.e., each low-level place 
(s,f) G U{S) contains as many tokens as the number of occurrences of v in the 
marking M of s. 

The unfolding can easily be extended to steps and step sequences, and one 
can observe that the step semantics obtained by unfolding the step semantics of 
an M-net N equals the step semantics obtained from U{N). 

Theorem 1 . Let N be an M-net. Then, U{steps{N)) = steps{U{N)). 

Proof. By definition of the unfolding and by the analogous property for inter- 
leaving semantics [4]. 



2.5 Algebra of M-Nets 

For compositionality, we are particularly interested in a sub-class of M-nets: we 
assume that each M-net has at least one entry and one exit place, that each 
transition has at least one input and one output place ( T-restrictness property) , 
and that there are neither arcs going to entry places nor from exit places. Such 
M-nets are said ex-good. 

The algebra of ex-good M-nets comprises the operations listed below, where 
Ni, N 2 and are M-nets, A is a hierarchical symbol, A is a synchronous 
communication symbol, b is an asynchronous link symbol and / is a renaming 
function on synchronous and asynchronous symbols. Detailed explanations and 
some examples of these operations are given in [4,10,17]. 



Ni[X^N2] 


refinement 


Ni[f] 


renaming 


N1WN2 


parallel composition 


Nisy A 


synchronization 


Np,N2 


sequence 


Ni rs A 


restriction 


N1UN2 


choice 


[A : AJ 


scoping 


[TVi * N2 * N3] 


iteration 


Ni tie b 


asynchronous links 



In the following the considered M-nets are ex-good, except if specified explicitly. 



3 Preemption 

In the following, we make a difference between programs (nets) and proeesses 
(actually, step sequences) which are their dynamic behaviors; each step sequence 
being a possible execution of its supporting net. 
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3.1 Abortion Versus Suspension 

When dealing with preemption, two notions are usually separated: suspension 
which “freezes” an execution but keeps it alive for a possible restart, and abortion 
which kills an execution definitively. Our approach deals with both of them, but 
focusing on abortion. More precisely, we treat abortion as a suspension followed 
by some processing in order to remove all the tokens from the net which supports 
the execution, making it unable to evolve anymore. This solution is based on 
priorities which make the problem of suspension quite straightforward to solve: 
in order to suspend a given net, it is enough to enable one of its transitions which 
has the priority over all the others. Actually this is what we propose: during all 
the abortion stage, there is always such a transition which is enabled and thus 
freezes the rest of the net when it is being emptied. 

3.2 Preemption and Time 

Preemption is often associated to time, at least intuitively, because it is expected 
to have an immediate effect on a system. As far as Petri nets are concerned, 
“immediate” means that no program transition may fire, from the beginning 
until the end of the preemption. Of course, in some other contexts, introducing 
time together with preemption makes sense, but it is not the case for our purpose. 
This is the reason why this paper never deals with time or time related concepts. 



3.3 Internal Versus External Abortion 

From the point of view of an execution, there is a difference between an internal 
abortion (when the execution “decides” to give-up its current work) and an 
external abortion (when the execution is killed by its environment). In both 
cases, the execution is suspended (i.e., no further transition in the corresponding 
net is allowed to fire, except, possibly, some well identified transitions involved 
into the abortion itself), and its supporting net must be “emptied” (he., tokens 
must be removed from the net). All the tokens have to be removed: first, because 
they make alive the execution being killed, and moreover, because the net must 
be cleaned up for a possible future re-usage, as the support of another execution. 

In the case of an internal abortion, however, the M-net must not be comple- 
tely emptied because its environment is not aware of the abortion and so waits 
for its completion. Actually, the environment is expecting the exit marking of 
the net which supports the aborted execution. As a consequence, the case of 
internal abortion corresponds to an anticipated termination, which reflects the 
abortion of the execution, followed by its completion through the production 
of the exit marking. In a way, internal abortion is a simple mean by which an 
execution can terminate “cleanly”, regardless of its current state. 

In the case of an external abortion, various behaviors may be acceptable since 
the environment is aware of the situation (by definition of external abortion, it 
is initiated by the environment). In our approach, we choose a solution where 
the aborted net fires a particular transition which warns its environment that 
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the abortion stage is over, but the exit marking is not reached. This way allows 
our construction to manage the abortion of nested executions quite elegantly: 
abortion is transmitted from the top to the bottom, from external executions to 
nested ones. 



3.4 Modeling Preemption in Petri Nets 

A preemptible Petri net should be able to run under two mutually exclusive 
modes: in “standard mode”, it processes its program; in “abortion mode”, it 
must stop its normal activity, empty and complete (reaching or not its exit 
marking). Abortion mode can interrupt standard mode, but not the reverse. 

On the one hand, we can consider that, before any move, standard mode 
checks that abortion mode is disabled. The execution checks the absence of 
token in the net part which supports abortion mode. This is a zero test, which 
can be modeled by introducing inhibitor arcs or complementary places. In this 
point of view, standard mode is responsible for freezing itself when necessary. On 
the other hand, we can consider that abortion mode has the priority over normal 
mode: if, in the net, transitions for normal mode and ta for abortion mode are 
both enabled, ta should be always preferred. This point of view naturally leads 
to consider priorities between transitions. Here, standard mode is completely 
passive with respect to its freezing. 

In this paper, we prefer the second point of view since it allows us to bring 
to the theory of priority systems as presented in [6] . Actually, M-nets extended 
with priorities and with a suitable definition of unfolding, lead directly to priority 
systems. This allows us to apply the main result from [6], which consists in 
transforming a priority system (A, p) in a Petri net Ep which is derived from S 
in such a way that it preserves as much as possible of the concurrency in E and 
does not violate the priority constraints specified by p. 



4 Preemptible M-Nets 

The purpose of this section is a definition of preemptible M-nets {P/M-nets for 
short), a class of composable M-nets provided with some additional information 
about priority between transitions and having some structural properties which 
ensure the soundness of their step semantics with respect to the semantics of pre- 
emption. For the definition of P/M-nets we proceed as follows: first, we consider 
an auxiliary and very powerful class of nets called priority M-nets, analogous to 
priority systems from [6], as M-nets equipped with a pairwise priority relation 
between their transitions. The transition rule of these nets takes into account 
the information about priority and so does the step semantics. Then, we ex- 
tend M-net operations to priority M-nets, giving to them an algebraic structure, 
and we define a new operation for priority M-nets, called tt, which serves to 
make preemptible any priority M-net. Finally, as the main definition of this sec- 
tion, we introduce P/M-nets as a sub-class of priority M-nets having interesting 
structural properties with respect to preemption. 
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Fig. 1. A marked priority M-net with p = {(^ 3 ,^ 2 )} (with simplihed annotations). 



4.1 Pairwise Priorities 

Let N = (S,T,l) be an M-net. A binary relation p CT x T is called a pairwise 
priority relation. Intuitively, (^1,^2) S p means that during an execution of N, 
the firing of transition t2 is always preferred to ti when both are enabled; in other 
words, ti has a lower priority than ^2- We use standard mathematical notations, 
in particular, for p Q T x T, we denote: 

dom{p) = {ti G T I 3^2 C T such that (^1,^2) G p}, 
cod{p) = {t 2 & T \ G T such that (^1,^2) G p}. 

4.2 Priority M-Nets 

A priority M-net is a pair P = {N, p) where N = ( 5 , T, l) is an M-net (possibly 
having some non T-restricted communication transitions) and p C T x T is a 
pairwise priority relation over T. We call N the net part of P. 

Definition 1. Let P = {N, p) he a priority M-net, M a marking of N = {S, T, l) 
and t a transition of N such that M[t); then t is p-enabled in P at M, denoted 
M[t)p, if$t' G T such that M[t') and {t,t') G p. 

Notice that p allows to disable a transition which would have been enabled 
with usual M-nets transition rule, but not the reverse. In other words, we have 
M[t)^ ^ M[t). 

The notion of step and step sequence defined for M-nets could be directly 
reused for priority M-nets. But, this way, they would lead to inconsistencies in 
the semantics. Consider for example the priority M-net P = {N, p) shown in 
figure 1 (taken from [6]), if we do not take p into account, we have the step 
semantics: 

steps{N) = { 0 , {tl},{t3},{fl,f3},{^l}{t3},{i3}{il},{fl}{f2}}, 
where 0 is the empty step sequence. 

We can see that it contains the sequence {ti}{t3} which violates p. Remo- 
ving this sequence is necessary but not enough since it introduces inconsistency. 
Actually, the semantics cannot contain {^1,^3} because {ti}{t3} is one of its 
linearisations. The consistent step semantics of P, denoted steps{P), is thus the 
biggest sub-set of steps{N) such that each step sequence D G steps{P) and each 
of its linearisations respect p. So, we have: 

steps{P) = { 0 , {fi}, {t3}, {ii}{i2}}- 
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According to [6] , this consistent step semantics is one of the most concurrent 
semantics one can expect for priority systems. 

The unfolding of priority M-nets is a natural extension of the unfolding of 
M-nets. 

Definition 2. Let P = (N,p) be a priority M-net. The unfolding of P, U{P), 
is a pair (U{N),U{p)) where U{N) is the usual M-net unfolding and U{p) is 
defined as the smallest set such that: for each pair (t, t') £ p such that t is 
unfolded into a set of low-level transitions {(<, tri ), . . . , (t, cr„)} and t' is unfolded 
into {{t',ai), . . . ,{t',ak')}, we have 0 -^), (t' , cr')) |l<i<nAl<j< 
k} Q U{p). If M is a marking of N , then U{M) is defined as it is for M-nets. 

As for M-nets, an extension of the unfolding of priority M-nets to consistent 
steps and consistent step sequences is straightforward and we still have: 

U{steps{P)) = steps{lA{P)). 

4.3 Algebra of Priority M-Nets 

The extension of usual M-net operations to priority M-nets is immediate for 
most of them. However, in the case of synchronization or refinement, several 
possible definitions of priority relation can be considered. Our choice is not the 
most general possible, we already have in mind the definition of operation tt and 
of P/M-nets. Priority M-nets are just an intermediate step which avoids circular 
definitions. 

Definition 3. Let Pi = (Ni,pi), for i £ {1,2,3}, be priority M-nets, where 
Ni = and let X be a hierarchical symbol, A a synchronous commu- 

nication symbol, b an asynchronous link symbol, and f a renaming function on 
communication symbols. The usual M-net operations are extended as follows for 
priority M-nets: 

— Pi[X ^ P 2 ] = {Ni[X ^ N 2 ],p) where 

p = {{t, t') ^ pi\Xi{t) ^ X ^ '^ 1(^01 

W {{tx -t,tx .t') I {t,t') £ p2 A tx & Ti A Xi{tx) = X} 

W {(tx-t,t') I t ^ cod{p 2 ) A {tx,t') £ Pi Atx £ Ti A X\{tx) = X}; 

— Pitieb = (Nitieb, pi); 

— Pi[f] = {Ni[f],pi); 

— Pisy A = (Ni sy A, p) where Ni sy A = (S, T, l) and p is is the smallest set 
including p\ such that if t' £ T results from a basic synchronization of t\ 
with t 2 , and 

— if3t” such that {t\,t") £ p or ft 2 ,t") £ p, then {t',t") £ p, 

— if3t" such that \t" ,t\) £ p or \t" ,t 2 ) £ p, then {t",t') £ p. 

— Pi rs A = {Ni rs A, p), where NiVsA= (S', T, t) and p = pi C\ {T x T) . 

Control flow operators (sequential composition (;), iteration ([* + *]), par- 
allel composition (||) and choice (Q)) are based on refinement and so defined 
canonically. Scoping is defined as a synchronisation followed by a restriction: 
[A : P] = (P sy A) rs A. 
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Fig. 2. Example of synchronization of priority M-nets. (Only synchronous labels are 
represented.) Restricting on A would remove from the net ti and t 2 (with their surro- 
unding arcs) and from its priority relation. 




Fig. 3. Ntt, net part of P-^ where type{c) = N and 1 ( 12 ) = i.{»,o}. Large black border 
of some transitions just indicates that they belong to cod[pT,). Inscriptions on the arcs 
are simplified: singletons are replaced by their unique element. 



4.4 A New Operation for Preemption 

In order to define operation tt, we use the priority M-net where 

An- is represented in figure 3 and the priority relation is 

Ptt = {(^71^4), (^7,^5), (tsyU), (^8,^5), ( hyh )}- 

The usage we make of is rather simple, even if the net may look quite 
complex: 
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— the top part (ei, tx and i\) embeds the net N from (N,p) which should 
be made abortable. When N terminates normally (with no preemption), 
transition to fires, consuming the token in place 62 and producing the exit 
marking in x~ 

— all the rest is used for preemption: internal abortion starts with a firing of t\ 
which produces a token • in place 12; external abortion starts when <2 or to 
fires, producing a token o. These two tokens allow to start the emptying of 
N; they are different in order to know, after the emptying is done, if may 
terminate producing the exit marking (for •, with transition t^) or should 
be completely emptied (for o, with tg); 

— transition ti is for internal preemption: it will be synchronized with all tran- 
sitions in N having a synchronous action quit in their label. This way, N 
may abort itself by firing such a transition. After t\ has fired and N has 
been completely emptied, tr can fire and terminate iV^r; 

— transition t2 is for external abortion: it may be synchronized later on with 
a transition such as fg, coming from another iV^ in which the present one is 
nested. This synchronization is not yet possible on the net of figure 3, but a 
further renaming kill' 1— >■ kill will allow it. After the emptying was completed, 
transition tg can fire and fully empty tg is intended to be synchronized 
with a transition such as to and, here again coming from ^n external Nt^', it 
will be made possible thanks to a further renaming empty' 1— >■ empty, 

— transition tg is similar to ^2 but is used when an external abortion occurs 
while an internal one is already in progress. It just replaces the token • in 
i2 with a token o. This corresponds to a switch from internal to external 
abortion mode. The priority (^2,^3) in Pit ensures that to is always preferred 
to t2 when both are enabled; 

~ emptying is performed by transitions <4, to and tg. We already had an in- 
tuition about the role of to and tg: the former triggers an abortion into a 
Ntt nested in N, doing this, it increments a counter handled through the 
links on c (this counter was initialized to zero by either ti or ^2); the latter 
allows such an aborted net to empty completely (by firing its transition tg), 
decrementing the counter; 

— the counter in c of killed sub-nets is used to ensure that each aborted sub-net 
is also emptied: as stated in definition 4, <4 and to have the priority over <7 
and tg, but tg has not. So, any possible firing of ti and to will be done before 
fr or tg have a chance to fire, then they must wait for tg to perform all the 
needed (and possible) emptying and thus to decrease the counter until zero. 
Finally, and not before, t^ or tg is allowed to perform communication c“(0); 

— the way ti works is not directly visible in Roughly speaking, for every 
place s in N , we will add an emptying transition ts with a synchronous action 
abort in its label and an arc s — >■ tg labelled with a singleton {a}, where a 
is an arbitrary variable. These transitions will be synchronized with ti and 
so, the loop on ti will be used to empty N, taking tokens one by one; 

— for convenience, the type of c has been set to N which leads, after unfolding, 
to an infinite number of places in the obtained low-level net. Fortunately, 
this type can easily be bounded in practice. 
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In order to have things working properly, we assume that actions symbols 
quit, kill, kill', empty, empty' and abort, their conjugated symbols and link 
symbol c are reserved for operation tt, and so are never used somewhere else. 

Operation tt relies on it first refines the net which should be made pre- 
emptible into Ptt and then adds the emptying transitions (such as tg) as de- 
scribed above (and formalized below). Scoping on quit allows internal preemp- 
tion, scoping on abort allows to control the emptying transitions and scoping on 
{kill, empty} allows the transmission of abortion to the potentially nested prio- 
rity M-n^te. A tiejm_c is also made so the counter can work properly. Finally, 
actions kill' and empty' are renamed in order to allow the result to be nested in 
another tt. 

Definition 4. Let P be a priority M-net. Then, 



tt{P) = [abort, quit, kill, empty} : A6(Pn.[A’ ^ P])tiec 

[kill' I— > kill, empty' i— > empty] 

where P^. is the priority M-net defined above and Ab is an auxiliary opera- 
tion which includes the additional emptying transitions; if Pt^[X •<— P] = P' = 
{{S',T',l'),p'), then Ab(P') = {{S" ,T" , l"), p") with: 

— S” = S', and Vs G S” : l”{s) = i'{s); 

— T" = P' l±l Ts where Tg = [tg \ s G S' \ {a;} A s* fl cod(p') = 0} 

i i'(t) ifteT', 

.y.cT.; 

-V((,.)er"xS":."(M) = '[Ilf: 

(i'{s,t) iftGT', 

— V(s,f) G S" X T" : i"{s,f) = < {a} C Var ift = tgG Tg, 

[0 iftGTg\[tg}; 

— p" = p'\S {{t,tg) \ tg GTg ht G Iftg)*}. 



Let us make two remarks about this definition: 

— places which are input places for transitions belonging to cod{p) (if P = 
(N,p)) are left untouched; the reason is that such places are already “under 
control”, i.e., belong to a nested emptying mechanism. We do not need 
additional emptying transitions for them; 

— the added emptying transitions are always synchronized with transition t^ 
in Ajj, whose enabling is well controlled. So, net 7r(P) never empties in an 
uncontrolled way. Another consequence is that the only non T-restricted 
transitions are those such as t 2 , fa and tg- 
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4.5 P/M-Nets 

We are now in position to define preemptible M-nets {P/M-nets). They are de- 
fined as a sub-class of priority M-nets with some structural constraints. This 
sub-class happens to be reasonably wide (see section 6) and sound with respect 
to the semantics of preemption (see section 4.6). 

Definition 5. Let P = {N, p) be a priority M-net. P is a P/M-net iff either: 

— N is an ex-good M-net and p = 0, or; 

- P is defined as tt{Pi), Pi[X ^ P 2 ], P1WP2, Pi\P2, Pi D^2, [Pi * P2 * P3], 
Pisy A, PiVsA, [A : Pi], Pitie& or Pi[/j, where Pi, for i G {1,2,3}, are 
P/M-nets, X is a hierarchical symbol, A is a synchronous communication 
symbol, b is an asynchronous link symbol, and f is a renaming function on 
communication symbols. 



Definition 6. A P/M-net (N,p) is said: valid if N is an ex-good M-net; finite 
iflA{N) is finite (in number of places and transitions) ; 1-safe ifU{N) is 1-safe. 

4.6 Soundness 

In order to define the soundness of a P/M-net P = (N,p) with respect to the 
semantics of preemption, we split the set T of transitions of N in four disjoint 
parts: T = l±l P; l±l Pi l±l Tp . 

If P = 7 t(P'), then, (r is for root) is the set of transitions involved in an 
abortion of P at the top level. In other words, P^ contains all the transitions 
coming from a synchronization with ti, or tg in used in tt(P'). (internal) 
contains the same kind of transitions, but issued from a possible tt nested in P' . 
Tt (termination) contains only transition coming from P,r in tt(P'). All the 
remaining transitions are in Tp (program). HP/ n(P'), we have = Tt = 0. 

Definition 7 below formalizes the intuition of the expected behavior of a 
preemptible M-net P. Actually, P can evolve in one of the following ways: 

— P runs without any abortion. In this case, it fires only transitions from Tp] 

— P runs as before by firing transitions in Tp until some abortions occur in 
some nested tt’s. In this case, all the next fired transitions are in W Pp; 

— P = 'k(P') and it completely aborts at a point of its execution. In this 
cases, it starts like in the previous case, until it begins aborting and thus 
only fires transitions from P^ or from because of some possible abortions 
transmitted to nested tt’s. After the end of the abortion, it may fire / from 
Tt to produce its exit marking. 



Definition 7. Let P be a P/M-net. steps(P) is said sound with respect to the 
semantics of preemption iff each D G steps(P) is of the form Si . . . SnS'i . . . S/5" 
or Si . . . SnS'i . ■ .5/ if P = Ti(P'), otherwise D = 5i . . . 5n, where for all j, 5j G 
Mf(Ti ttiPp), for all k, S'f. G Mf(Ti WPr), and 5" = {ff G P*}. 
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{A}.0.0 



e 

e 




{(/uit}.0.0 



X 

X 



Fig. 4. Net part of P/M-net Pi = {Ni, pi) with pi — 0. All the places of Ni have type 
{•}, and arcs should be annotated {•}. 




Fig. 5. The scheme for P 2 , its priority relation is p 2 = 0- 



By induction on the algebraic structure, we get that what we structurally de- 
fined through P /M-nets is what we expected as a model preserving the semantics 
of preemption. 

Theorem 2. Let P he a P/M-net. Its step semantics, steps{P), is sound with 
respect to the semantics of preemption. 



5 A Detailed Example 

This section gives an example of P/M-net. We show the construction of the 
P/M-net 

P = tt{tt{Pi)\\P2) 

where Pi is a P/M-net with two parallel transitions ta, labelled {A}. 0.0, and ti, 
labelled {(7mt}.0.0 (see figure 4). P 2 is a net from which we will just consider 
one transition tc having one internal input place ic', we assume that this net is 
valid, well defined and does not use n in its construction (this would demonstrate 
transmission of abortion but, for the sake of simplicity, we prefer to show this 
feature with Pi only). P 2 is schematized in figure 5. This example allows us to 
illustrate internal and external abortion as well as the propagation of abortion to 
nested tt operations. In the following, most annotations are omitted from figures 
in order to keep them as readable as possible. 

First, let us look carefully at the P/M-net produced by tt{Pi) whose con- 
struction is detailed in figures 6 to 8. The first step for building tt{Pi) is to 
refine Pi into Pt^ and to add the emptying transitions; the net part of the result 
is shown in figure 6 and the coresponding priority relation is 

Pi = {(^7,^4), (^8,^4), (frAs), (isAs), {ta,ts), 

{tt, t/, {to, t'J, {ta, h), {tb,t5), {t 2 , to)}- 

The next step consists in performing the scoping over kill and empty, making 
asynchronous links over c, and renaming kill' into kill and empty' into empty, 
as stated in definition 4. The result is sketched in figure 7 (most annotations are 
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Ml--- 




Fig. 6. Net part of Pt^[X -<r- Pi] with the added emptying transitions. See figure 3 for 
the detailed annotations. 



omitted as well as place Sc for asynchronous links on c). Transitions tf, and t\ 
yield a new transition whose firing starts internal abortion stage. The synchro- 
nization of with the added emptying transitions yield and t". Transitions 
ts and fg are removed because they are nothing to synchronize with (it will not 
be the case later in our example, when we will consider the nesting of 7 t(Pi) into 
another tt). The priority relation of 7 t(Pi) is 



Pi = (^6,^4), (^0,^4)) (^7,^4): (^8,^4)! (^2,^3)}- 



One can observe that everything works right when this net is started from its 
entry marking: if (internal abortion) or t2 (external abortion) fires, then the 
net is correctly emptied, whenever ta did fire or not. Similarly, if tg fires after 
did. The difference between external and internal abortion appears at the 
very end: for internal abortion, ty fires, producing the exit marking; for external 
abortion, only tg can fire. We will see later in the example how ^2, O and tg are 
synchronized in order to achieve a correct transmission of abortion when 7 t(Pi) 
is nested into another tt. 

The communication transitions, related to the preemption and visible from 
the outside of 7 t(Pi), are ^2, H and tg. So, in the following, 7r(Pi) will be schema- 
tized as shown in figure 8. (Notice that we show only one entry place while there 
are actually two, this has no other consequence than simplifying the figures.) 

In order to finish our example, we have to put 7 t(Pi) in parallel with P2 
and to apply tt on the result. We get the P/M-net depicted (in a simplified 
version) in figure 9. The net resulting from 7 t(Pi)||P 2 is splitted in two parts, 
the part coming from P2 corresponds to the gray box in the top and the part 
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{A}.0.0 




Fig. 7. Simplified vr(Pi). Transitions labels are 0.0.0, except on ta, t2, ts and tg. 

{kUl}.<D.9 



{kill}.<D.<D t 


= i 


1 ^ 


8 {empty}. 0.0 


© 




7t(Pi) 




0 



Fig. 8 . A really simplified representations of 7 t(Pi). 



which comes from 7 t(Pi) corresponds to the box in the bottom. The middle part, 
which is not boxed, comes from the last application of tt. For this final P/M- 
net, the priority relation is p = 

(^7,^5), . . .}. 

We can see that an abortion has three effects: one is the emptying of P 2 with 
transition (there would be much more transitions like if P 2 would be larger) , 
one other is the emptying of entry and exit places for the parallel composition 
7 r(Pi)||P 2 (with transitions t\ and fl), and the last is the propagation of the 
emptying to 7 t(Pi) (with transition or t'l). When this sub-abortion is done 
and when all P 2 is empty (which can be done in any order, even in parallel), 
can fire, ending the emptying of 7 t(Pi). 

We can also observe that suspension is immediately effective. Thanks to the 
definition of p,r, tc is suspended as soon as is enabled (and it is disabled after 
^4 fired). Similarly, transitions in 7 t(Pi) are first suspended as long as tg and 
tg are enabled and, when of them one fires, the suspension is done internally 
because ^ 4 , t" and t'(' in 7 t(Pi) are then enabled (see figure 7). 

In this final net, transition ty is dead because the net never uses internal 
abortion; even if sub-net 7 t(Pi) does, it is not the case for 7 r( 7 r(Pi)||P 2 ) as a 
whole. 
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Fig. 9. A simplified representation of the P/M-net resulting from 7r(7r(Pi)||P2)- 



Asynchronous links on c (even if not shown in the figures) ensure that the 
propagation of abortion to 7 t(Pi) is always followed by its complete emptying, 
through a firing of transition tg (see figure 9). 

Let us conclude this example noticing that the net we obtain is ready to be 
nested in another tt, like tt{Pi) was, thanks to its own transitions t 2 , and tg. If 
no such nesting is to be made, the net should be restricted over kill and empty, 
resulting in a valid P/M-net. This restriction would be necessary, not only for 
validness, but also in order to avoid a spontaneous firing of transition t 2 or tg 
which would result in an unexpected abortion of the net. 

6 Properties of P/M-Nets and Links with Existing Works 

Let us observe first that a P/M-net {N,p) which has been constructed without 
operation tt is always valid and has p = 0. This property states that the intro- 
duced extension is conservative and does not disturb the existing model if one 
makes no usage of operation tt. This is the reason why we consider P/M-nets 
as a “reasonably wide” model: it contains M-nets which already proved being 
useful. 

However, in general, a P/M-net P = (N,p) can have some crippled tran- 
sitions. It turns out that they can easily be identified by their synchronous 
label {empty} or {kill}. These transitions belong to the communication inter- 
face of P and are crucial in order to nest P in another operation tt, e.g., in 
P' = 7t{. . . P . . .). Operation tt, thanks to the scoping on kill and empty, al- 
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lows P' to abort its preemptible parts such as P. However, if P is not to be 
nested in an operation tt, then these crippled transitions should be removed. 
Actually, in that case, the P/M-net of interest is Prs {kill, empty}. Moreover, 
Prs {kill, empty} is valid; this property is important because it shows that even 
if our modeling needs to relax the T-restrictness of some transitions, the final 
result can always be T-restricted. 

Valid P/M-net semantics may still appear as somehow unsatisfactory, be- 
cause of the use of priorities. It turns out that some results in the field of se- 
mantics of priority systems may be applied for P/M-nets. In [6], the authors 
define a transformation of a finite 1-safe Petri net S, equipped with a pairwise 
priority relation p, into a bounded Petri net which retains as much as possible 
of the concurrency of (S,p). In this context, as much as possible means that 
only semantics composed of consistent steps are considered (see [6, section 3]). 
This result can be directly applied to the unfolding of a valid, finite and 1-safe 
P/M-net. (One can see that if P is 1-safe, so is tt{P).) Then, applying the re- 
sult from [7], the obtained bounded Petri net can be transformed into a 1-safe 
Petri net which has the same pomset semantics (partially ordered multi-sets 
semantics), and we can state: 

Proposition 1. Let P be a valid, finite and 1-safe P/M-net. Then, P can be 
transformed into a low-level 1-safe Petri net having the same consistent step 
semantics. 

So, P/M-nets can be transformed, in most of reasonable cases {i.e., finite 
ones), into 1-safe Petri nets having an equivalent concurrent semantics. However, 
the construction given in [7] leads to really huge nets and so is not intended to 
be used in practice. Nevertheless, the above proposition is important since it 
means that 1-safe Petri nets are expressive enough to model preemption with a 
concurrent semantics. 

In practice, it should be possible to modify the existing model checker of 
PEP [13,11] in order to have it dealing with priorities. The model checker relies 
on finite prefixes computation: it develops the branching process semantics of 
the analyzed low-level net until it finds a maximal cut. (This is always the 
case in finite 1-safe Petri nets since the number of states if finite.) Under such 
conditions, the influence of priorities should be to prune some branches in the 
computation. For two enabled transitions ti and t 2 , the existing algorithm would 
build one branch starting with a firing of ti and another for t 2 . With priorities, if 
(ti, ^ 2 ) S p, the branch starting with t\ does not have to exist anymore. This does 
not mean that the computation would be more efficient; actually, the contrary 
should hold: adding priorities would force the examination of much more cases 
in order to take into account some possibly disabled transitions, because of 
priorities. However, the model checking remains decidable. 

7 Conclusion 

We presented what is, to the best of our knowledge, a first attempt to provide 
a fully compositional model of Petri nets with a preemption operator, with a 
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concurrent semantics. Our construction is based on M-nets which are extended 
with priorities, structured into an algebra and structurally restricted leading to 
preemptibles M-nets {P /M-nets). The P/M-net algebra is similar to the M-net 
algebra, but having an additional operation tt, which transforms any P/M-net 
into its preemptible equivalent. 

We show that P /M-nets can be considered as a high-level version of so called 
priority systems (as defined in [6]) by defining an unfolding operation which 
transforms a P/M-net into a low-level Petri net having priorities between its 
transitions. Thus, applying results from [6] and [7], any reasonable P/M-net can 
be transformed into a 1-safe Petri net (without priorities) which retains as much 
as possible of the concurrency present in the P/M-net. This transformation leads 
to enormous nets and is not tractable in practice, but it shows that 1-safe Petri 
nets are powerful enough to model preemption with a concurrent semantics. 

The presented work has been already applied for giving the semantics of some 
preemption-related extensions of the parallel programming language B(PN)^, 
introducing abortable blocks, treatment of exceptions, a generalized timeout 
construct and a small Unix- like process manager. 

Acknowledgments. We are very grateful to all the participants of the three 
last PORTA/BAT workshops for their remarks on this work and especially for 
their thoughts about model checking nets with priorities. Particular thanks go 
to Raymond Devillers. 
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Abstract. Test generation is a program-synthesis problem: starting 
from the formal specification of a system nnder test, and from a test 
purpose describing a set of behaviours to be tested, compute a reactive 
program that observes an implementation of the system to detect non- 
conformant behaviour, while trying to control it towards satisfying the 
test purpose. In this paper we describe an approach for generating sym- 
bolic test cases, in the form of input-output automata with variables and 
parameters. 



1 Introduction 

It is widely recognized that testing is an essential component of the full lifecycle 
of software systems. Among the many different testing techniques, conformance 
testing [11] is one of the most rigorous. The usual theoretical approach [5,16] is to 
consider a formal specification of the intended behaviour of the Implementation 
Under Test (lUT). It allows to define the notion of conformance relation, which 
defines the correct implementations with respect to the specification. It also 
allows to formally define test cases, their execution on an lUT, and the notion 
of verdict associated to the execution. However, the process of writing test cases 
for large specifications is complicated, error-prone and expensive. For example, 
the paper [12] identifies various errors in about 15% of the test cases from a 
commercially available test suite for the SSCOP protocol [21]. Another difficulty 
comes from the black-box nature of the implementation, whose behaviour is only 
observable and controlable at the interfaces. In this context, a formal framework 
is a prerequisite for giving precise and consistent meanings to test cases. 

During the last decade, testing theories and algorithms for the automatic 
generation of tests have been developed from specifications modelled by variants 
of the Labeled Transition System model (LTS). Some efficient algorithms are ba- 
sed on adaptations of on-the-fly model-checking algorithms [13]. Academic tools 
such as TorX [1], TGV [6] and industrial tools such as TestComposer (Verilog) 
already exist, which implement these algorithms and produce correct test cases 
in a formal framework. However, these theories and tools do not explicitly take 
into account the program data, as the underlying model of LTS implies that 
values of variables are expanded during state exploration. This may result in the 

* The specifications and proofs for the example treated in the paper can be found at 
http : //www . irisa.fr/pampa/perso/rusu/IFMOO/. 

W. Grieskamp, T. Santen, and B. Stoddart (Eds.): IFM 2000, LNCS 1945, pp. 338—357, 2000. 

(c) Springer- Verlag Berlin Heidelberg 2000 
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classical state-explosion problem, but also has the effect of obtaining test cases 
where all variables are instantiated. This is in contradiction with industrial prac- 
tice, where test cases (written, for example, in the TTCN language [11]) are real 
programs with parameters and variables. Generating such test cases requires new 
models and techniques. The models should explicitly include parameters and va- 
riables, and the techniques should treat them symbolically by combining model 
checking with constraint propagation, static analysis, and theorem proving. In 
this paper, we present some steps towards such an approach. 

The rest of the paper is organized as follows. In Section 2 we define an exten- 
sion of the LTS model (called lOSTS) to include parameters and variables. In 
Section 3 we define subclasses of the lOSTS model that are used for specificati- 
ons, test purposes and test cases. We adapt a conformance relation from [16] to 
the model of lOSTS. In Section 4 we define a notion of correctness of test cases 
with respect to specifications and test purposes. In Section 5 we describe how to 
generate test cases by successively computing a synchronous product between 
a specification and a test purpose, eliminating internal actions and nondeter- 
minism, and selecting the behaviours that are accepted by the test purpose. 
(Currently, the method works only for specifications for which internal actions 
and non-determinism can be eliminated using a given set of heuristics.) We also 
prove the correctness of the generated test cases. In Section 6 we show how to 
simplify the test case using static analysis and theorem proving to remove irrele- 
vant control and data. The approach is demonstrated on a simple example: the 
BRP protocol [8]. 

2 Model: Input-Output Symbolic Transition Systems 

We define a model of extended transition systems called Input-Output Symbolic 
Transition Systems (lOSTS), inspired from I/O automata [15] and CSP [10]. The 
lOSTS model was designed to be easily translatable into the input languages of 
tools such as the PVS theorem prover [17] and the HyTech model checker [9]. 

Syntax. Let be a set of typed data. We denote by type{d) the type of element 
d £ D,hy £{D) the set of type-correct expressions on the data D, and by B{D) 
the subset of boolean expressions. 

Definition 1 (lOSTS). An lOSTS is a tuple {D,0,Q,q^, S,T~) where 

— D is a nonempty, finite set of typed data, which is the disjoint union of a 
set V o/ variables, a set P o/ parameters and a set M o/ messages, 

— 0 £ B{V U P) is the initial condition, 

— Q is a nonempty, finite set o/ locations, 

— £ Q is the initial location, 

— S is a nonempty, finite alphabet, which is the disjoint union of a set 17* of 
input actions, a set S° o/ output actions, and a set y™* o/ internal actions. 
For each action a £ y*U 17°Ui7*”*, there is a (possibly empty) tuple of types 
sig{a) = (di, . . . , dk) , called the signature of the action (the signature of an 
internal action a £ y*"* is the empty tuple). 
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rn = 0 A head = 1 A max > 1 A last 




> 0 



head < last 
ACK? 

head := head + 1, rn := 0 



head = last A rn > 0 
CONF_DONT_KNOW! 



Fig. 1. Example of lOSTS: the Sender of the BRP Protocol. 



— T is a set o/ transitions. Each transition consists of: 

• a location q G Q, called the origin of the transition, 

• an action a G E called the action of the transition, 

• a tuple of messages p = {mi, . . . , mk) such that if sig{a) = {di . . . dk) 

is the signature of action a, then, for all i G type{mi) = d^, 

• a boolean expression G G B{V UPUp), called the guard of the transition, 

• a set of expressions A, called the assignments of the transition, such that 
for each variable x G V there is exactly one assignment in A, of the form 
X := A^ , where A^ is an expression on V U P U p, 

• a location q' G Q called the destination of the transition. 

Figure 1 illustrates an example of lOSTS, which has variables /, rn, head, para- 
meters max and last, and messages F and m. We assume that rn, head, max, 
and last are natural numbers (with max > 1, last > 0), variable / and message 
F are functions from natural numbers to some unintepreted type (which is also 
the type of message m), and for all f G N, F{i) ^ F{i + 1). 

Consider for example the transition with origin Send-File and destination 
WaiPAck. It has the action MSG with message m, guard m = f{head— 1), and 
assignment rn := rn + 1, f := f, head := head. In the graphical representa- 
tion, the symbol ? (resp. !) denotes an input (resp. an output) action, and the 
assignments without effect (such as f := f) are omitted. 

Semantics. For D' Q D a. subset of the data, we denote by Val(D') the set 
of (type-consistent) valuations of D' , which associate to each element oi d G D' 
a value of type type{d). A state is a pair (l,v) where I G Q is a, location and 
V G Val{V U P) is a, valuation for the variables and the parameters. We denote 
the set of states by S. An initial state is a state {Iq,vo) such that Iq = q^ (the 
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initial location) and vq\= 0. We denote by 5° the set of initial states. A valued 
input (respectively a valued output) is a tuple consisting of an input action a G 
(resp. an output action a G S°) and a tuple of values of the types given by the 
action’s signature. That is, if a S 17* and sig{a) = . . . di), then valued inputs 

are of the form (a, . . . , vi) where for all i G [1, 1], Vi is a value of type di (and 

similarly for valued outputs). We denote by T (resp. 17) the set of valued inputs 
(resp. of valued outputs.) 

Let D',D” C D denote two disjoint subsets of D. For v G Val(D') and 
w G Val(D"), we denote by v-w the valuation of D'UD” such that v-w{d) = v{d) 
\i d G D' and v ■ w{d) = w{d) if d G D” . Given an expression e G £{D) and a 
valuation v G Val{D), we denote by v{e) the value obtained by replacing in e 
each element d G D hy its value v{d). The semantics of an lOSTS is given by a 
labeled transition system with set of states S, initial states S^, labels 7’U17UI7*"‘, 
and the transition relation — S x (T U 17 U 17*"*) x S, which is the smallest 
relation defined by the following rule: 

{q,a,p,G,A,q') G T 

V, v' G Val{V U P), w G Val{fi), v ■ w{G) = true 

\/x GV \ v'{x) = V ■ w{A^) \/x G P : v'{x) = v{x) 

<a,w> . . 

<q,v > ^ < q',v' > 

The relation — ^ induces the relation =^C S' x (17 U T)* x S by dropping 
all internal actions: 

— s ^ s' ‘^= 3ri, ...TnG 17*"‘, 3si, . . . s„_i G S,s ^ si • • • s„_i ^ s’, 

— for a e 17 U T, s s' 3si ,S 2 GS,s si S 2 s' 

— for cr = oi ••• G (17 U T)" with n > 1, s s' '^= 3si, . . . s„_i G S, 

Q!L an / 

5 ■ ■ * Syj— 1 ^ S . 

For an lOSTS S we denote by traces{S) the set {a G (17 U T)*|3so G S°,3s G 
S, So s}. For cr G (12 U T)*, we denote by S after a the set of states {s G 
S|3so G S°, So s}. For S' C S a set of states, we denote by out(S') the set of 
valued outputs that can be “observed” in states s' G S' possibly after internal 
actions, that is, out{S') = {a G 12|3s' G S', 3s G S, s' s}. For a set of traces 
L, we denote by pref{L) the set of strict prefixes of sequences in L. 



Subclasses of lOSTS. Let S be an lOSTS, P its set of parameters, and 
7T G V al{P) a valuation of the parameters. By replacing each parameter p G P 
by its value 7r(p), we obtain an lOSTS denoted S(7 t), called an instanee of S. 
In this case, we also say that S(7 t) is instantiated. An instantiated lOSTS is 
initialized if the initial condition O assigns to each variable v G V exactly one 
value. An arbitrary lOSTS is initialized if all its instances are initialized. An 
lOSTS S is deterministic if for all s G S: card(UT-g^int{s' G S'|s — > s'}) < 1 
and for all a G 17U T, card{{s' G Sjs s'}) < 1. That is, for each state s G S, 
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if an internal action is executed, then the next state depends only on s, and if a 
valued input (or valued output) a is executed, then the next state depends only 
on s and a. We then have the following proposition: 

Proposition 1 . If TC is an initialized, deterministic lOSTS without internal 
actions, then for all a € traces{'TC), the set of states TC after a is a singleton. 

A location q of an lOSTS is input- complete if for each state s =< q,v >€ S 
and each valued input a G T, the set {s'|s => s'} is nonempty. An lOSTS is 
complete if for each sGS”, aGl 7 UTU A™*, the set {s'|s s'} is nonempty. 

Operations on lOSTS. For an lOSTS S with alphabet 175 = 27^14 E° U A™* 
and two disjoint sets of actions A®, A° with A® U A° C A® U A°, we denote by 
mirror{S, A®, A°) the lOSTS which is the same as S except for its input and ou- 
tput actions, which are (A® \A®)UA° and (A°\A°)UA®, respectively. We denote 
by mirror(S) the operation mirror(S, T°). Intuitively, mirror(S,S^ ,S°) 
replaces in the lOSTS S all the actions from A® with actions from A°, and 
reciprocally, while mirror{S) transforms all inputs of S into outputs and reci- 
procally. 

We now define a generic composition operation for lOSTS, which we then 
specialize to define two operations (parallel and product) that are needed in the 
sequel. For two lOSTS 5 i = (Ai, 6>i, Qi, Ai, Ti) with data Di = ViUPiUMi 
and alphabet Ai = A} U A} U A}"' (resp. ^2 = (I?2, 6>2, Q2, -^2, T2) with 

data A2 = V2 U P2 U M2 and alphabet A2 = A2 U A2 U A“*), we say 5 i, 52 are 
compatible for composition if {V\ U Mi) fl {V2 U M2) = 0 , (Pi U Mi) fl M2 = 0 , 
(P2 U M2) n Ml = 0 , A} = A2, A} = A2, and each action a £ A} U A2 (which 
also means a £ A° U Ef) has the same signature in both systems. Note that the 
two systems may share some parameters, and that a variable of one system may 
be a parameter of the other (meaning that it can be read, but not modified). 

The composition operation lets each system perform independently its inter- 
nal actions (that are not in the alphabet of the other), and imposes synchroniza- 
tion on the shared actions. Formally, the composition S = 5i|52 of compatible 
lOSTS 5 i,^ 2 is the lOSTS {D,P,0,Q,q^ ,S,T) that consists of the following 
elements: A = V} U A2, P = (Pi U P2) \ (Ai U V2), M = Mi U M2, 0 = 6»i A 02, 
g = Qi X Q2, q° = (g?, q^). A® = 0 , A° = Ai° U A^, A®®®* = A®®®‘ U A^®®‘. The set 
T of transitions of the composed system is defined as follows: 

— for each transition {qi,a, p,, G, A, q'f) £ Ti with a £ A“* \ A™* and for each 
location of the form (51,52) with 52 £ Q2, there is in 5i|52 a transition 
{{qi,q2),a,p,G,AVJ[}y^y^{y := y},(5'i,52)) (and similarly for all actions 
a £ A“* \ A®®®*), 

- for each transitions (51, a, /xi, Gi, Ai, g'l) £ Ti, (52, a, M2, G2, A2, 5®2) £ T2 
with a £ A(, let Gi_2 (resp. ^1^2) denote the expression obtained by replacing 
in G2 (resp. A2) each message from /j,2 by the corresponding, same-position 
message from /ii- Then, in 5i|52 there is a transition ((51, 52), o, Mi, G'l A 
Gi^2,Ai U Ai^ 2, (g'l, 5'2)) (and similarly when a £ A| or a £ A(®®‘ fl A™*). 
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Parallel operation. The parallel operation || is the same as the composition |, 
except that it is defined only for lOSTS Si,S2 that satisfy the stronger compa- 
tibility requirements Di fl D2 = 0, if™* H if™* = 0- We use this operation to 
model the execution of a test case on a black-box implementation. 

Product operation. The product operation x of lOSTS 5i, 1S2 is defined as 
iSi X ^2 = mirror{Si\mirror{S2), Sf). The compatibility requirement for 
the product operation (in addition to the fact that 5i and mirror{S2) must be 
compatible for composition) is if™* = if™*. We use this operation during test 
generation to select a part of a specification, by computing the product with 
another lOSTS called a test purpose. For precise selection, we allow the test 
purpose to have access to the specification’s internal actions and data. 

We are interested in the following relationships between the traces of the 
parallel and product-composed systems and the traces of their components. 

Proposition 2 (Traces of the Parallel and Product Compositions). For 

lOSTS Si, S2 that are compatible for the parallel (resp. product) composition: 

1. traces{Si\\S2) = traces{Si) fl traces{S2) 

2. if S2 is complete, then traces(Si x ^2) = traces{Si). 

Sketch of Proof. To prove the first item, we show that for all states si,s( of 
Si (resp. S2,S2 of ^2), and for all valued input or output a € l7i U Ti (which 
also means a G T2 U ^2), the relation (si,S2) (S11S2) holds in 5i||52 iff 

Si s*i holds in iSi and S2 s'2 holds in 1S2. For this, we first prove that 
internal actions of each system leave the state of the other unchanged (which 
is true essentially because of the hypothesis that the data of the two systems 
are disjoint), and that, for a valued input (or output) a, a transition relation 
involving a exists in the composition if and only if it exists in both components. 
For the second item, we first note that the traces of an lOSTS S2, and those 
of S2 modified by a mirror operation, are the same. Thus, it is enough to 
show that, for lOSTS 5i and 52 that are compatible for the |-composition, 
which have the same internal actions, and such that S'2 is complete, the equality 
traces{S i\S'2) = traces{Si) fl traces{S'2) holds. For the C inclusion, we proceed 
in the same manner as for the corresponding inclusion in item 1 (here, the 
data independence hypothesis is not used) and we use the fact that (since S'2 
is complete), traces{S'2) = (T2 U 172)* = (l7i U Ti)*. For the 3 inclusion of 
item 2, we use again the fact that S'2 is complete: by composing it with 5i, any 
sequence of valued actions which is present in the latter is also allowed by the 
former, therefore it is also present in the composition 5i|52. □ 

3 Conformance Testing with lOSTS 

Conformance testing [11] is a methodology for validating reactive systems. It 
consists in testing a conformance relation between a specification, which is a 
formal model of a system, and an implementation of the system, which is a 
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physical process (typically, a program running on a machine) that can only be 
controlled and observed at its interfaces. This is done by running test cases on the 
implementation and obtaining verdicts about the conformance. In general, three 
kinds of verdicts are distinguished. Informally, Fail means that non-conformance 
was detected. Pass means that the implementation behaved in conformance with 
the specification and the goal of the test experiment (described by the a so-called 
test purpose) has been reached, and Inconclusive means that the implementation 
behaved correctly but, due to the lack of control on the implementation, it did 
not allow to reach the expected goal. We model specifications, implementations, 
test purposes and test cases as lOSTS, with some restrictions for each category. 



Specifications. A specification is an initialized lOSTS. In this paper we con- 
sider (for test generation) specifications without cycles of internal actions. We 
then indicate how to extend the approach to allow cycles of internal actions that 
perform internal, deterministic, computations, during which the system does not 
communicate with its environment. 

As a running example, we use the specification of the BRP protocol [8], which 
was designed to safely transmit files over an unsafe medium. The protocol uses a 
combination of alternating-bit and resend-on-timeout mechanisms. Here, we are 
only interested in the sender of the protocol, which is represented in Figure 1. 
The parameters last (resp. max) stand for the number of packets in the file being 
sent (resp. the maximum number of retransmissions of a packet). The variable 
head is used to count the packets (which are /(O) to /{last — 1)) and variable rn 
is for counting retransmissions. On reception of a REQ input with messsage F 
from its client, the sender saves it in variable /, then iteratively sends the packets 
using the output action MSG with message m. A packet can be acknowledged 
(input ACK), or there may be a timeout (an internal action), after which the 
sender decides to resend the same packet. The status of the whole transmission 
is described by either CONF^OK, meaning that all the packets were sent and 
acknowledged, CONF_DONT_KNOW, meaning that all the packets were sent 
and all but the last were acknowledged, or CONF_NOT_OK, meaning that some 
intermediary packet was not acknowledged. 



Implementations. An implementation is a physical object. However, in order 
to be able to formally reason with it, we assume (this is a usual “testing hypothe- 
sis”) that the implementation can be modelled by an lOSTS, which is unknown 
except for its input and output alphabet and the signatures of its actions, which 
are supposed to be the same as those of the specification. 

Test Purposes. A test purpose is used to select a part of the specification, 
for which a test case will be generated. A “good” test purpose should be simple 
(typically, much simpler than the specification) and should select exactly the 
scenarios that the user has in mind. In practice, as our experience with the tool 
TGV [13] , the process is iterative: a first test purpose only grossly selects a part 
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n = f{j -1) Aj < last 
MSG!(n) 
j := J + 1 



Fig. 2. A Test Purpose for the BRP Sender. 



of the specification, then the user has to examine the result and modify the test 
purpose, and repeatedly so until a satisfactory result is obtained. Here, we use 
lOSTS as test purposes and the product operation as the selection mechanism. 
This gives enough expressiveness for describing, e.g., parameterized scenarios 
that would be hard to describe with, e.g., finite automata or temporal logic. 

Formally, let S = (T>s, 6>s, Qs, ifs, Ts) be a specification lOSTS. A test 
purpose of S is an lOSTS TV = {Drv, Qtv, 9r-pi ^tv^Ttv) together with 
a set of locations Aceept^^ C such that TV is initialized, complete, x- 
compatible with S, and all the transitions with origin in the set Accept^^ are 
self- loops. 

The lOSTS represented in Figure 2 is a test purpose for the specification of 
the BRP sender. It is used to select the scenarios in which the latter sends all 
messages exactly once (without retransmissions) and exits successfully with a 
CONF-OK confirmation. It has the variable j, parameters / and last (which are 
also a variable, respectively a parameter of the specification), and one Accept 
location. The location Reject is used to discard executions in which the BRP 
sender does not behave as intended (i.e., it executes the internal action timeout, 
known to be followed by a retransmission, or it exits with a wrong confirmation). 

This test purpose is not complete but, by convention, it is implicitly com- 
pleted as follows: in each location, any action that does not (syntactically) label 
an outgoing transition, will produce a self-loop; and any action that labels some 
outgoing transition with a guard G, will generate a transition to Reject with the 
guard -'G. This simplifies the writing of test purposes by allowing to focus on 
the intended behaviour for testing, leaving practically irrelevant details (such as 
completeness) to the test generation tool. 

Given a specification S and a test purpose TV oi S, we define the product 
V = S X TV, the set of locations Accept-p = x Accept^-p, and the set of 
traces of the product Atraces{V) = {a € {Tp\jTp)*\3sQ € Sp,3s = {l,v) & Sp \ 
I € Acceptp,so =^p s}. By Proposition 2 item 2, we know that Atraces(V) C 
traces{S). Intutively, Atraces{V) is the set of traces of the specification that are 
selected (through the product operation) by the test purpose. 

The product between the BRP sender and its test purpose is partially repre- 
sented in Figure 3. 
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rn = 0 A head = 1 A j = 1 A max > 1 A last > 0 



m — f{head — 1)A 
(/(/lead - 1 ) 7 / f(j - 1 ) 
Vj > last) 

MSG?(m), / := / + 1 

rn := rn + 1 



head < Zast 

ACK! 

head := head + 1 , 
rn := 0 




head = last + 

A j 7 ^ last + 1 

/lead = /ast\^ CONF.OK? 
A rn > 0 

CONF_DONT_KNOW? 



head = last A rn > 0 
CONF_DONT_KNOW? 



Fig. 3. Product of Sender and Test Purpose (partially represented) 



Test Cases. Test cases are used to assign verdicts to implementations. This is 
done by running the two systems in parallel, and by observing the state of the 
test case at the end of the interaction. Formally, a test case is an initialized, deter- 
ministic lOSTS, together with three disjoint sets of locations Pass, Inconclusive 
and Fail. Moreover, a test case should react promptly to any input from the 
implementation, thus, it should not have internal actions, and all its locations 
(except those in the set Fail U Pass U Inconclusive) should be input-complete. 

An example of test case is represented in Figure 4. It starts by giving to the 
sender’s implementation a file F to transmit. Then it expects to receive the suc- 
cessive packets in the file, and tries to acknowledge each packet. If it succeeds and 
receives the CONF_OK confirmation, the verdict is Pass, as the implementation 
behaved in conformance with the specification and the test purpose is satisfied: 
all packets were sent without retransmission. If, however, the test case gets ano- 
ther copy of the packet that it has just received, this means that the sender 
performed a retransmission, and the verdict is Inconclusive', the implementation 
behaved in conformance with the specification, but it did not allow to satisfy 
the test purpose. Finally, if some other input is received, the verdict is Fail, as 
the implementation emitted an output that is not allowed by the specification. 
For simplicity, the locations Fail are not represented in Figure 4. 



Verdicts. We formalize the notion of verdict. Let TC be a test case. We denote 
by Pass (respectively Inconclusive, Fail) the set of states of TC whose loca- 
tions are in the set Pass (resp. Inconclusive, Fail). Let I be the implementation 
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head = 1 A last > 0 




Fig. 4. Example of Test Case for the BRP Sender. 



under test. For a trace a G traces{I\\TC), we write verdict{TC, I ,a) = Pass if 
TCafter a C Pass. We introduce the notations verdict{TC , I , a) = Fail and 
verdict{'TC , I, a) = Inconclusive in a similar way. 



Conformance. The conformance relation links an implementation with in- 
stances of the specification and the test purpose. Indeed, in practice, implemen- 
tations are compared against specifications with known values of the parameters. 

Definition 2 (Conformance Relations). Let S{tt) be an instance of lOSTS 
S, TV he a test purpose for S, V = S x TV their product, and V{tt) = (5 x 
TV){n) the corresponding instance of the product. 

1. An implementation I is conformant to the instance S{tt) of the specification 
S, denoted Iconf S{'k), if for all traces a G traces{S{'K)) : out{I after a) C 
out{S{Tr) after a). 

2. An implementation I is conformant to the instance S{'k) of the specification 
S and relative to the test purpose TV, denoted Iconf.j..j, S{'k), if for all 
a G pref{Atraces{{S x TV){'k))) : out{I after a) C out(iS(7r) after a). 

That is, after each trace of the specification, the possible outputs of the im- 
plementation are included in those of the specification. In the second case, the 
inclusion should hold after each prefix of a trace of the specification that is 
selected (through the product mechanism) by the test purpose. 
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4 Correctness of Test Cases 

We formalize what it means for a test case to be correct, relative to a given 
specification and test purpose and for a given class of implementations. The 
intuition is that any instance of the test case should always give the right verdict 
when executed on an implementation in the class. 

Definition 3 (Correctness of Test Cases). Let S be a specification, TV a 
test purpose of S, and X a set of implementations. Let TC he a test case such 
that the parameter sets of TC and S are the same, and tt a valuation of the 
parameters. 

— TC is sound for S,X if for every instance TC{tt) and implementation L G I, 
if there exists a € troces(/||TC(7r)) such that verdict{TC{'K),I,a) = Fail, 
then I is not conformant to S{tt). 

— TC is relatively complete for S,TV,X if for every instance TC{tt) and im- 
plementation I G I: if L is not conformant to S{n) relative to TV, then 
there exists a G traces{L\\TC{Tr)) such that verdict{TC{'K),I ,a) = Fail. 

— TC is accurate for S,TV,I if for every instance TC{tt), implementation 
I G I, trace a G traces{I\\TC{'iT)): verdict{TC{'K),I ,u) = Pass iff a G 
Atraces{{S x TV){tt)). 

— TC is conclusive for S,TV,I if for every instance TC{tt), implementa- 
tion I GX, trace a G traces{L\\TC{'n)): verdict{TC{Tr) , I , a) = Inconclusive 
implies a G traces(S(7r)) and a ^ pref{Atraces{{S x TV){'k))). 

A test case TC is correct for S,TV,X if it is sound for S,X and relatively 
complete, accurate and conclusive for S, TV, X. 

Intuitively, soundness means that the test case rejects only non-conformant im- 
plementations (in the given class). Relative completeness means that the test 
case can detect all implementations in the given class, which are non-conformant 
with the specification relative to the test purpose. (It does not mean all these 
implementations will actually be detected, because of nondeterminism of the 
implementation and because there may be an infinity of traces to consider.) 
Accuracy means that the verdict Pass is given when the observed trace of the 
implementation is a trace of the specification that is selected by the test pur- 
pose. Finally, conclusiveness means that the verdict Inconclusive is given when 
the observed trace of the implementation is a trace of the specification, but it 
cannot be extended into a trace that eventually produces the verdict Pass. 

5 Test Case Generation 

We present a procedure for generating symbolic test cases that are correct in 
the sense of Definition 3. The first step is computing the product between the 
test purpose and the specification, which was defined in Section 3. The following 
steps consist in transforming and simplifying the product (e.g.. Figure 3) to 
obtain a test case (e.g.. Figure 4) with all the required properties. 
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Fig. 5. Sequence of Internal Actions. 



Closure: Eliminating Internal Actions. A test case should react promptly 
to inputs from the implementation. A natural way to obtain this is by requiring 
that every location of a test case (except the verdict locations) is input-complete. 
However, the possible inputs in a location may be hidden by internal actions. 
For example, consider the location WA^Pl of the lOSTS represented in Figure 3. 
Here, the system can only send an output ACK! or execute the internal action 
timeout, but the inputs {MSG?, CONF_OK?, etc) can only be executed after 
a timeout. To make the location input-complete, we first have to eliminate the 
latter actions. Thus, to obtain test cases where all locations are input-complete, 
all internal actions have to be eliminated from the product V — S x TV. For 
this, the idea is to compute the effect of any sequenee of internal actions that 
leads to an input-labeled transition, and to encode it in the last transition. This 
gives a simple syntactical procedure, which works if the specification does not 
contain cycles of internal actions. (A way to handle cycles is proposed at the end 
of this section.) 

More formally, let ri , T 2 , . . . , r„ be a sequence of internal actions that leads to 
an input action a (cf. Figure 5). The guard and assignments corresponding to 
are Gi, Ai, and the guard (resp. assignments) corresponding to a are G, A. Then, 
it is not hard to see that a trace-equivalent system is obtained by replacing the 
whole sequence by a transition with origin li, destination ln+ 2 , action a, guard 
Gi A {G 2 o Ai^ A . . . {Gji o Aji_i o • • • o A]^) A {G o Aj, o Aji_i o • • • o A^), and 
assignments A o A„ o A„_i o • • • o Ai, where o denotes function composition. 

We obtain an lOSTS V with the same traces as V, but without internal 
actions. The set of accepting locations Accept^ is defined by Accept^ = fl 
Aecept.p. For the product lOSTS represented in Figure 3, the corresponding 
lOSTS without internal actions is represented in Figure 6. The differences come 
from the transitions labeled timeout, which have disappeared, and whose guards 
(rn < max, resp. rn = max) have been propagated to the nearest observable 
transitions. 



Determinization. Nondeterminism is prohibited in test cases, because the 
verdicts should not depend on internal choices of the tester. Thus, the following 
step is to eliminate nondeterminism from the lOSTS V. This means computing 
another lOSTS denoted [P], which has the same traces as V (and thus, the 
same traces as the product V = S x TV), but without nondeterministic choices. 
The typical case of nondeterministic choice is represented in Figure 7: an (input 
or output) action a leading to two different effects on the variables and/or the 
control. 
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rn = 0 A head = 1 A j = 1 A max > 1 A last > 0 







m — f(head — 1)A 
(f(head - 1) 7 ^ f(j - 1) 
Vj > last) 

MSG? (m) j ~ j + 1 

_rn := rn + 1 ^ 



3 



REQ!{F) 
f ~ F 



> 



rn < maxA 

— f(head — 1) 

MSG?(m), 

rn := rn + 1 



m — f(head — 1)A \ 

f(hea^-l) = f(j - 1)\ 
Aj < last 
MSG?(m) j := j + 1, 
rn \= rn + 1 



head < last 

ACK! 

head := head + 1 
rn := 0 




rn — maxA 
head = lastA 
rn > 0 

CONF_DONT_KNOW? 



head := head + 1 

head = last + 1 A j = last + 1 
CONF_OK? T"wT2_Accei^ 



head = last A rn > 0 
CONF_DONT_KNOW? 



Fig. 6. lOSTS of Figure 3, after Elimination of Internal Actions. 




(determinization) 




Fig. 7. Determinization. 



Eliminating nondeterminism in a symbolic transition system is a difficult pro- 
blem in general. Here, we propose a simple heuristic that takes care of common 
situations, such as the one represented in Figure 7 . The idea is to postpone the 
effect of a nondeterministic choice on the observable actions that follow it. In the 
situation represented below, this amounts to splitting the two transitions (with 
guards Gi, G2 and assignments Ai, A2) into three: one for the case G\ A -'G'2 
holds, another for the case when G2A-'Gi holds, and the last for the case Gi AG2 
holds. In the latter case, the choice whether to assign the variables according 
to Ai or to A2 is postponed until the observable action that follows. A new 
location 52,3 is introduced, which we call a copy of locations ^2, <73- Thus, if h 
is the next action, then the assignment A\ should have been executed, and it 
is composed with the guard and the assignment corresponding to b (which pro- 
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duces the guard G 3 o Ai and assignement A 3 o Ai). Similarly, if c is the next 
action, then A 2 should have been executed, which produces the guard G 4 o A 2 
and assignement A 40 A 2 . Of course, if b and c are actually the same action, then 
the same scheme has to be applied again, and the whole procedure might not 
terminate. It can be shown that it does terminate if the maximal sequence of 
actions involved in nondeterministic choices (such as the sequence composed of 
action a in Figure 7) does not produce cycles in the graph of the lOSTS. Also, 
knowing that some guards are mutually exclusive can help the determinization 
procedure to terminate. For example, determinization leaves the lOSTS repre- 
sented in Figure 6 unchanged, because wherever there are transitions with the 
same origin and labeled with the same action {MSG?, ACK!) and with several 
possible outcomes, the corresponding guards are mutually exclusive. 

We associate to the lOSTS \P] (obtained after product, closure and determi- 
nization) a set of accepting locations Accept^], which is the union of Accept^ 
and of the set of new locations produced by determinization, which are copies 
of some location in Accept^. 



Selection. The next step consists in selecting a part of the control graph of the 
lOSTS [P] that leads to the set of locations Accept^^^ , and in adding transitions 
to a new location fail, such as to make the lOSTS input-complete. We define 
three subsets of the set of locations Qpi as follows: 

— let Pass denote the set Accepf^^ 

— let Leads2Pass denote the set of locations q € Qfp] \ Pass such that, in the 
graph (Q[ 4 >j ,T[ts]), there exists a path (i.e., a sequence of contiguous locations 
and transitions) from the initial location to q and from q to Pass 

— let Inconclusive denote the set of locations q' £ Q[n]\ Pass \ Leads2Pass 
such that there is a transition in T [pj with origin in Leads2Pass, destination 
q', labeled by an input a G 

Let also fail denote a new location {fail ^ Q[v])- We define the test case as an 
lOSTS TC = (T>rc,6’rc,Qrc,9rc;^roTrc) as follows: £>rc = Ore = 
^\v]i Qtc = Pass U Leads2Pass U Inconclusive U {fail}, qf^ = q^^^ (if gjbj ^ 
Pass U Leads2Pass then the test case is not defined). The alphabet of the test 
case is ^tc = The set of transitions Trc consists 

of the transitions of T pj with origin and destination in Pass U Leads2Pass U 
Inconclusive, and of a set of new transitions, with origin in every q G Leads2Pass 
and for each input a G Sfe- Every such new transition leads to fail, and, for a 
given origin q and action a, its guard is the negation of the disjunction of all the 
guards of transitions in T[pj, with same origin q and action a. The assignments 
of the new transitions are empty. They are used to make the test case input- 
complete, by letting go to fail, from any state, any valued input that is not 
allowed by the specification. 

For the lOSTS partially represented in Figure 6 , the selection operation eli- 
minates precisely the parts that are not represented. The set of locations Pass 
consists of only one element {WT2-Accept). The set Inconclusive consists of 
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locations W A^Reject, WT2_Reject. For simplicity, the location fail, and the 
transitions leading to it, are not represented. By comparing the lOSTS in Fi- 
gures 6 and 4, it is clear that the former still needs considerable simplification. 
This is the role of the simplification operations, which we describe in more detail 
in the next section. 

However, the lOSTS TC obtained so far has all the properties required from 
a test case: it is input-complete (this is obtained by adding the new transitions 
to fail), it is initialized (this is inherited from the specification and the test 
purpose, and is preserved by subsequent transformations), it is deterministic 
(this is obtained by closure and determinization), and furthermore: 

Proposition 3 (Correctness of Test Generation). For any specification S 
and test purpose TV of S, the test case TC obtained from S and TV by test 
generation is correct for S, TV, and the class of implementations that have the 
same inputs, outputs, and signatures as S. 

Proof outline. We have to prove that the four properties of definition 3 (so- 
undness, relative completeness, accuracy and conclusiveness) hold. First, it is 
easy to see that, by construction, TC has the same parameter set as S and 
that, for an arbitrary implementation / which has the same inputs, outputs, 
and signatures as S, I is compatible with TC for parallel composition. (Thus, 
the valued inputs of I are the valued outputs of TC and reciprocally.) We consi- 
der an arbitrary instance TC{tt) of TC, and the corresponding instances S{n) of 
the specification S and {S x TV){tt) of the synchrounous product S x TV. As 
in Section 3, we denote by Pass (respectively Inconclusive and Fail) the set 
of states of TC{n) whose locations are in the set Pass (resp. Inconclusive and 
{fail}). In the following proofs, we implicitly make use of Proposition 1 (i.e., 
when we say a trace a brings the TC(t:) in a given location, we implicitly assume 
that TC{'K)aftera is a singleton). 

Soundness : Let a G traces{I\\TC{-K)) such that verdict{TC{Tr) , I , a) = Fail. By 
the first item of Proposition 2, cr is a trace of / and a trace of TC(7 t). By definition 
of verdict, we obtain TC{Tr)aftera C Fail, meaning that cr leads the test case 
to the location fail. Consider the prefix a' of cr obtained by removing its last 
valued action a. By construction of the test case, we obtain that cr is a valued 
input of TCijr) (thus, a valued output of /), cr' G traces{{S x TV){tt)), and a = 
<t' ■ a ^ traces{{S x TV){tt)). Using the second item of Proposition 2, we obtain 
that a' G traces{S{'K)) and a ^ traces{S{Tr)), thus, a ^ out{S{Tr) after cr'). But 
cr = cr' • a is a trace of / and a is a valued output of I, thus a G out{I after a'). 
Hence, I does not conform to S{tt). 

Relative completeness : Suppose that I does not conform to S{tt) relative to 
TV. By definition of conf there exists a trace cr' G pref{Atraces{{S x TV){tt))) 
and a valued output a of the implementation such that a G out{I after a') 
but a ^ out{S{'K) after a'). We choose a trace a' which is minimal with this 
property, and let a = a' ■ a. Thus, cr G traces(I) and cr ^ traces{S{'K)). From 
cr' G pref{Atraces{{S x TV){tt))) and the minimality of cr, we obtain (by con- 
struction of the test case) also a' G traces{TC{iT)) and {TC{n) after cr') fl 
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{FailU Pass U Incon) = 0; thus, a' brings the test case in a location q which 
is not in Pass U Inconclusive U {fail}, thus q is input-complete. But a is also an 
input of the test case, thus, the trace a = a' ■ a is also in traces(fTC{T:)) . Now, 
cr € traces{TC{'n)) and a ^ traces{S{'K)) implies, by construction of the test 
case, that TC{tt) after a C Fail. As a € traces{I) and a € traces{TC{'K)), we 
obtain, by the first item of Proposition 2, that a G traces{I\\TC{'K)) . The latter 
together with FC{tt) after a C Fail implies verdictfTC{'K) , /, a) = Fail. 
Accuracy : By definition, for a trace a G traces{I\\TC(Tr)), verdict{TC{'K),I,u) 
= Pass iff FC{tt) after a C Pass. By construction of the test case, the traces 
of FC{tt) leading to a state in the set Pass are exactly those in Atraces{{S x 
TP){t^)), which proves the property. 

Conclusiveness : By definition, for cr € traces (/||TC(7 t)), verdict{‘TC{7r),I,a) = 
Inconclusive iff FC{tt) after a C Inconc. If a leads to a state in the set Inconc, 
by construction of the test case, cr is a trace of {S x T'P){tt), thus (by the second 
item of Proposition 2), cr G traces{S{Tr)). We prove the second part of the 
property by contradiction. If we had a G pref{Atraces{{S x TV){t^))), then, by 
construction of the test case, the location of TC{tt) after a would be in the set 
Leads2Accept, not in Ineonclusive. This concludes the proof. □ 



Cycles of Internal Actions. We consider a class of specifications that contain 
cycles of internal actions, and for which it is still possible to generate test cases 
with all the correctness properties except relative completeness (cf. Definition 3) . 
This class includes specifications described, e.g., in an imperative programming 
language, where cycles of internal actions correspond to deterministic control 
structures like iterations or recursions. For a specification S with locations Q and 
transitions T, let 7““* C F denote the subset of transitions labeled by internal 
actions (which we call for short internal transitions). Let Q*"* C Q denote the 
set of locations such that all transitions with origin in Q*”* are internal. We call 
Q™* the set of internal loeations. 

The test generation process is redefined in the following way. The product 
operation is unchanged. The elimination of internal actions is applied only to 
internal transitions whose origins are in Q \ Q™*. (Thus, if these transitions 
do not form cycles, the operation terminates, as for example in the case of the 
lOSTS represented in Figure 3). The determinization operation is the same, and 
the selection operation is unchanged, except that it does not add transitions 
leading to fail from the internal locations. 

To show that the obtained test case TC is correct (expect for relative comple- 
teness), we prove the soundness, accuracy and conclusiveness like in the proof of 
Proposition 3. (However, we cannot use Proposition 1 any more, since FC now 
has internal actions). The proof of relative completeness does not work, because 
of the internal locations, which are not input-complete. Intuitively, the test case 
can miss some inputs while it is executing its internal actions. In practice, this 
problem can be fixed by buffering the inputs for later observation. 
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6 Simplifying the Test Cases 



The test generation procedure defined in the previous section consists essentially 
of syntactical transformations (which extend the algorithms implemented in the 
tool TGV [13] to handle symbolic data). Although it does produce correct test 
cases (e.g., the one represented in Figure 6), the latter are almost never what the 
user would expect (e.g., something like Figure 4). Indeed, there are unreachable 
parts, redundant variables, guards and assignments can be simplified, etc. Thus, 
we need semantic-based simplification techniques that preserve the correctness of 
test cases. We present an experiment with the HyTech model checker [9] and the 
PVS theorem prover [17] for simplifying the test case of the BRP, and indicate 
other potentially useful techniques. 



rn = 0 A head = 1 A j = 1 A max > 1 A last > 0 




Fig. 8. Test Case after Elimination of Irrelevant Control using HyTech and PVS 



We define translations of lOSTS into the HyTech and PVS input languages. All 
the corresponding files (PVS specifications and proofs, and HyTech scripts) can 
be downloaded from http://www.irisa.fr/pampa/perso/rusu/IFMOO/. 



Translation to HyTech. HyTech is a model checker originally designed for hybrid 
systems verification. It handles discrete variables (integers) through a polyhedral 
library [7]. We had to modify the tool to re-include a widening operator that 
forces convergence of fixpoints. As HyTech does not handle uninterpreted fun- 
ction symbols, the translation of the test case represented in Figure 6 involves 
replacing every conjunct containing the uninterpreted function symbol / with 
true. Also, the actions become uninterpreted labels of the HyTech transitions. 
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Translation to PVS. PVS is a general-purpose theorem prover with a rich input 
language (typed higher-order logic). Consequently, the translation of lOSTS into 
PVS preserves all the information and is straightforward. 

Simplifying the Test Case. The simplification of the test case represented in 
Figure 6 is done in two steps. First, HyTech (with widening) is used to automa- 
tically generate a set of linear invariants^. This gives the following output: 

Location: Pass 

rn = 1 & head = last +1 & head = j & head >= 2 & max >= 2 

Location: Inconclusive 

j = head +1 & head >= 1 & rn >= 1 & max >= 2 & head <= last 

Location: SC_P1 

rn = 1 k head = last +1 k head = j k head >= 2 k max >= 2 

Location: WA_P1 

rn = 1 & j = head +1 & head >= 1 k max >= 2 k head <= last 

Location: SF_P1 

rn = 0 k head = j k head >= 1 k max >= 2 k head <= last 
Location: WR_P1 

rn = 0 k head =1 & j = 1 k max >= 2 k last >= 1 

Thus, e.g., whenever control is at location SF^Pl, the relation rn = OAhead = j 

A head < last holds between the variables of the lOSTS. This is useful informa- 
tion: in particular, it shows that location WT2. Reject is not reachable, thus, it 
can be eliminated, together with all six transitions leading to it. This also in- 
dicates another transition that could be eliminated: the transition from SF_P1 
to W A_Reject. This is because its guard /{head — 1) yf f{j — 1) V j > last, in 
conjunction with the invariant produced by HyTech, evaluates to false. However, 
HyTech cannot evaluate conditions with uninterpreted function symbols, thus, 
the simplified lOSTS, together with the generated invariants, are translated to 
PVS, which automatically proves the following invariant: 

"/iproved (transition from SF_P1 to Inconclusive is never fireable) 
transl_never_f ireable : LEMMA invariant (NOT LAMBDA (s : State) : EXISTS (m: Msg) : 
control (s)=SF_Pl AND m=f (s) (head(s) -1) AND(j (s)>last OR m/=f (s) ( j (s)-l) ) ) 

This allows to eliminate the transition from SF_P1 to W A_Reject, which pro- 
duces the lOSTS represented in Fig. 8. Other simplifications are then made: 
given the invariant relations between head and j in locations SF_P1, W A_P1, 
and SC -PI, it is clear that j can be replaced by head and eliminated altogether 
from the lOSTS, since it has no more influence on the variables. The same holds 
for rn, as the only test rn < max on this variable always evaluates to true. 
Finally, we obtain the test case represented in Figure 4. 

Clearly, other program analysis and verification techniques can be useful for 
symbolic test generation. We are investigating slicing [22] (see [4] for a use of 
slicing techniques in the context of conformance test generation), and automa- 
tic theorem-proving in rich, yet decidable theories such as WSIS [14] or the 

^ Inconclusive in the HyTech output corresponds to W A_Reject in Figure 6. 
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quantifier-free fragment of Presburger arithmetic with uninterpreted function 
symbols [20]. Integrating these algorithmic and deductive techniques into an 
environment for symbolic test generation is a longer-term project. 

7 Conclusion and Future Work 

In this paper we describe some basic steps towards the generation of symbolic test 
cases in the form of extended transition systems with parameters and variables. 
The approach generalizes existing work on test generation using enumerative 
methods [1,6] . The generated test cases satisfy some correctness properties, which 
means essentially that they always emit the right verdict. To be useful in practice, 
the test cases have to be simplified using automated static analysis and proof 
strategies. This is a first direction for continuing work. 

Another future work direction (with the same goal of obtaining simpler test 
cases) is to generate test cases from an abstraction of the specification, rather 
than from the (concrete) specification itself. The usual notion of abstraction 
(over-approximation, cf. [2]) cannot be applied here, because of the asymetry 
between inputs and outputs in the conformance relation. Over-approximating 
the outputs of the specification is acceptable (the test cases remain sound, alt- 
hough they lose completeness and accuracy), but over-approximating the inputs 
may lead to unsoundness (the test case explores behaviours that are not in the 
specification, which may produce false Fails). We need abstractions that over- 
approximate the outputs and under-approximate the inputs. 

Third, symbolic test cases need to be instantiated before they can be execu- 
ted. An analysis of their behaviours, depending on their parameters and messa- 
ges, may be useful to find domains of equivalent values. Then, under uniformity 
hypotheses [3] it is enough to instantiate the parameters and messages to one 
value in each domain. Also, test generation needs two inputs: specifications and 
test purposes. Designing test purposes by hand from the specification can be 
difficult, in particular if a good coverage of the specification is targetted. We 
believe that classical structural coverage criteria [19], combined with symbolic 
analysis, may yield interesting test purposes. 

Finally, the techniques described in this paper can be used in (or fertilized 
by) techniques of other domains. In particular, there are obvious similarities 
between test generation and controler synthesis [18], where a controler has to be 
derived from the specification of a program with respect to a control plan. 
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Abstract. We propose an integration of diagrammatic object oriented modeling 
techniques with a formal specification and verification technique. We translate 
UML class diagrams to B abstract machines in a way that does not only pro- 
vide a formal interpretation of the class diagrams but that also allows us to verify 
properties of object oriented models within the framework of the B method. Spe- 
cifically, we address translating generalization / specialization hierarchies to B. 
An appropriate construction of B components allows us to express and formally 
verify behavioral conformance, which ensures that polymorphism can be used 
safely. Expressing the proof obligations associated with behavioral conformance 
by constructing B components makes it possible to use the tool AtelierB for me- 
chanically verifying them. 



1 Introduction 

The Unified Modeling Language (UML) [14] has become a de-facto standard notation for 
describing analysis and design models of object-oriented software systems. The mostly 
graphical description of models is easily accessible. Developers and their customers 
intuitively grasp the general structure of a model and thus have a good basis for discussing 
the requirements of a system and their possible implementation. 

When it comes to more detailed questions, however, the fact that the UML lacks a precise 
semantics is a serious drawback. Thus, even if it is in principle possible to document 
requirements in some detail, for example, describe a behavioral constraint on a method, 
its semantics is unclear. This can result in misconceptions by developers or customers. 
The imprecise semantics also hinders the development of tools for analyzing models 
that achieve more than just a syntactic check of mutual consistency between models. 
An approach to ameliorate that deficiency is to map part of the UML to a formal language 
with a precise mathematical semantics and - hopefully - tool support. We use the B 
abstract machine notation [1] for that purpose. In previous work [11], we have shown 
how to represent class diagrams and statecharts by B abstract machines. 

In the present paper, we focus on the generalization / specialization relationship in UML 
class diagrams. We present an automatable mapping from UML class diagrams to B 
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abstract machines. Roughly, we map a UML class to a B abstract machine. Thus, one 
machine represents the objects of a particular class. We then augment the resulting B 
specification by logical properties that are not described in the UML class diagram. 

We use the refinement relation defined for B abstract machines to analyze the classes in a 
generalization / specialization relation for behavioral conformance. This is the semantic 
relation between classes that allows the clients of a class hierarchy to use polymorphism 
safely. The tool AtelierB [19] generates verification conditions for B abstract machines 
that allow us to prove behavioral conformance between classes that are described in 
UML. AtelierB also supports proving those verification conditions in an interactive 
fashion. 

In Sect. 2, we motivate the concept of behavioral conformance by way of an example. 
We define behavioral conformance independently of the B formalism. In Sect. 3, we 
represent UML classes by B machines. In Sect. 4 and Sect. 5, we show how the proof 
obligations generated by AtelierB relate to the definition of behavioral conformance 
given in Sect. 2. Section 4 considers the operation refinement conditions on the methods 
that are present in the more general class of a generalization / specialization relation. 
Section 5 deals with the condition on history constraints that is relevant for so-called 
extra methods of the more specialized class of a generalization / specialization relation 
that do not have a counterpart in the more general class. We use a number of auxiliary 
machines to obtain proof obligations in B that correspond to the obligations for the 
history constraint. Section 6 summarizes our experience with the tool AtelierB. We 
conclude in Sect. 7 by relating our work to the work of others and discussing what we 
have achieved. 



2 From Class Diagrams to Behavioral Conformance 



We motivate the analysis we carry out for generalization / specialization relationships 
by way of an example taken from [9]. The purpose of this section is to introduce the 
concepts informally. Formal definitions have been given for algebraic specifications in 
[9] and for an object oriented extension of Z [18] in [15]. 

Figure 1 shows a UML class diagram for two specializations of bags. The class Bag 
models a container data structure that is a multi-set. Bag is a generic class: it is para- 
meterized with the type ELEMENT. For each item i of type ELEMENT, the attribute 
elements counts the number of occurrences of i in the bag. The attribute bound is the 
maximal number of items that a given bag can contain. An instance of the class has three 
operations: newBag creates a bag with a given bound, get returns an arbitrary item in 
the bag and deletes it from the bag, and put adds a new item to the bag. 

The classes DynamicBag and StaticBag are two specializations of Bag. An instance of 
DynamicBag may change the value of its bound : the operation chgJbound may increase 
the value of bound to the value of its parameter, but no operation on a dynamic bag 
may decrease the bound of the bag. The constraint attached to the class box of StaticBag 
requires that the bound of a StaticBag cannot be changed. Additionally, the operation 
get is specialized by StaticBag: for an instance of StaticBag, get returns the item that 
the bag contains most often. 
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Fig. 1. UML class diagram: the bag hierarchy 

Behavior specification. The class diagram in Fig. 1 does not provide information about 
the intended behavior of the classes as described by the preceeding explanatory text. 
When we translate that diagram to a B model in Sect. 3, we will augment the information 
derived from the class diagram with specifications of the behavior of the operations of 
the classes. 

Specialization versus behavioral conformance. If we model a generalization / specia- 
lization relationship as the one of Fig. 1 , we wish to know whether or not that relation is 
a behaviorally conforming specialization. If a specialization is behaviorally conforming, 
then instances of the subclass can safely be used where instances of the superclass are 
expected, i.e. polymorphism is safe. By “safe”, we mean that the behavior that an object 
exhibits if it is accessed through the interface of the superclass conforms the expectations 
one has about the behavior of instances of the superclass - there are no “surprises”. 

For example, if we access an object through the interface of Bag, we should have no way 
of determining whether that object is an instance of DynamicBag, StaticBag, or a proper 
instance of Bag. If the specialization was not behaviorally conforming, then it would 
be unsafe to polymorphically assign an instance sbag of StaticBag, say, to a variable of 
type Bag, because then using sbag as if it were an instance of Bag might lead to runtime 
errors or otherwise undesired behavior of the implemented system. 

Extra methods. As America [2] pointed out, behavioral conformance' is strongly related 
to classical data refinement. Liskov and Wing [9] extend America’s definition by taking 

' America and others call behavioral conformance “behavioral subtyping”. We avoid the term 
“subtyping”, because behavioral conformance is a logical relation that is independent of a 
particular type system. 
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extra methods into account. Extra methods are the operations of a subclass that are 
not present in the interface of its superclass. For example, the operation chgJbound of 
DynamicBag is not defined for arbitrary Bags. 

In the presence of aliasing, extra methods may provoke “unexpected” behavior. Consider 
an instance dbag of DynamicBag. If we access dbag only through the interface of Bag, 
there is no way of changing dbag. bound. If, however, dbag is accessed through the 
interface of DynamicBag, then the bound may be changed by calling dbag.chgJbound. 
That change then is observable through the interface of Bag, for example, by reading 
the value of the attribute bound. 

Is changing the value of bound “unexpected” for an instance of Bag! The answer depends 
on the interpretation of what behavior Bag specifies. A very conservative view might 
argue that changing the bound is indeed unexpected, because Bag provides no way of 
doing so. With that view, the expected behavior of a class would be inductively defined 
by the state transitions that its operations allow. That view is too restrictive for realistic 
cases. In [15], we have studied the container hierarchy of the Eiffel Base Libraries [10]. 
The root class in that hierarchy does not have an operation which changes the state of an 
object. With the restrictive notion of behavioral conformance, any specialization of that 
class which modifies the container would not behaviorally conform to the superclass. 
Posing no restrictions on the behavior of extra methods is also not adequate. Then, a 
DynamicBag could be a specialization of StaticBag, contradicting the constraint that the 
bound of a static bag must not change. 

History constraints. Those considerations have led Liskov and Wing [9] to propose the 
concept of a history constraint as an additional means to specify the acceptable behavior 
of the instances of a class. We [15] have translated their definition from the context of 
algebraic specifications to model-based specifications in Object-Z [17]. In that context, 
a history constraint HC{s, s') is a binary relation between the states of the objects of a 
class, such that 

- it respects the invariant I of the class, i.e. I{s)AHC{s, s') I {s'), and that 

- the specifications of all operations Op - viewed as relations between before and 
after states - respect the history constraint, i.e. I{s)AI{s')AOp{s, s') =A HC{s, s'). 

Thus, a history constraint may be regarded as an anonymous operation that provides all 
possible behaviors of objects of a class - including the objects of any specialization of 
the class. If H{s, s') satisfies those two conditions, we call the class specification history 
consistent^ . 

Behavioral conformance. Given the concept of a history constraint, we can define be- 
havioral conformance more precisely: A class C behaviorally conforms to a class A 
if 



- C is a data refinement of a A if we view both classes as abstract data types, and 

^ History consistency is a necessary condition for the internal consistency of a class specification 
[15]. The other conditions that make up internal consistency are similar to the ones on B 
abstract machines enforced by the B method (c.f. Sect. 4.2), e.g., that the initialization of a 
class establishes the invariant and that operations preserve the invariant. 
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- the history constraint of C implies the history constraint of A, HCc => HCa- 

The first condition ensures that any redefinition of an operation in a specialization is 
a refinement of the overwritten operation. The second condition ensures that any extra 
method - which must conform to the history constraint of C - conforms to the history 
constraint of A, i.e. it does not exhibit unexpected behavior. 

3 From UML Class Diagrams to B Abstract Machines 

3.1 The B Method 

B [1] is a formal software development method that covers the software process from the 
specification to the implementation. The B notation is based on set theory, the language of 
generalized substitutions, and first order logic. Specifications are composed of abstract 
machines similar to modules or classes; they consist of a set of variables, invariance 
properties relating those variables, and operations. The state of the system, i.e. the set of 
variable values, is only modifiable by operations. Machines can be composed in various 
ways. Thus, large systems can be specified in a modular way, possibly reusing parts 
of other specifications. Refinement of a B model allows developers to derive a correct 
implementation in a systematic way. Refinement can be seen as an implementation tech- 
nique but also as a specification technique to progressively augment a specification with 
more detail. At every stage of the specification, proof obligations ensure that operations 
preserve the system invariant. A set of proof obligations that is sufficient for correctness 
must be discharged when a refinement is postulated between two machines. 

3.2 Integrating UML and B 

This section presents the translation of some of the UML class diagram concepts into a B 
specification. We focus on the formalization of classes and inheritance. More information 
on our integration of UML and B can be found in [ 1 1 ] . Most of the B machines we present 
in this and the following sections can be generated automatically from the UML model. 
Only the parts of the machines shaded gray must be added manually. 

Classes, attributes, and methods. A formal representation of the class Bag shown in 
Fig. 1 is given in Fig. 2. We describe a class by an abstract machine which models a 
collection of instances. Names of formal parameters are expressed in brackets after the 
name of the machine. The abstract machine defines the constant BAG which is the set 
of the identities of possible instances of the class. Therefore, it is a subset of the set 
INSTANCES of all possible object identities. The set of identities of existing instances 
is modeled by the variable bag. 

Because a B machine represents all instances of a class, not just a particular object, we 
model attributes by relations between object identities and attribute values. Depending 
on the attribute characteristics specified in the UML class diagram, a relation between 
object identities and attribute values can be restricted further. For instance, if the attribute 
is mandatory and mono-valued, then the relation modeling that attribute is required to 
be a total function. Thus, we have two functions in Fig. 2, elements and bound, which 
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MACHINE Bag(ELEMENT) 

CONSTANTS 

BAG 

PROPERTIES 

BAG C INSTANCES 

VARIABLES 

bag, elements, hound 

INVARIANT 

bag C BAG A 
elements G 

bag ). [ELEMENT )- NAT) A 

hound G hag — v NAT 

INITIALISATION 

hag, elements, bound := 0, 0, 0 

OPERATIONS 

newBag[bnd) = 

pre 

hnd G NAT A 
not[BAG — bag) 

then 

any new where 

new G BAG — bag A 

then 

bag := hag U {new} || 
elements{new) ELf'MEA'rx {0} || 
bound[new) := 

end 

end; 



rmvBag[oo) = 

pre 

oo C hag 

then 

:= bag — oo \\ 
elements := oo elements || 
bound := oo bound 

end; 

e/r ■< — get[oo) = 

pre 

G bag 

then 

any // where 

a G ELEMENT A 

(I'l) > 0 

then 

(??) ; = 

elements[oo){ii) — 1 || 
elt ;= // 

end 
end ; 

pLit[oo, a) = 

pre 

oo G A 
a G ELEMENT A 

< MAXINT 

thin ' 

elements[oo)[ii) ;= e/eme’«A(o<9) (//) + 1 

end; 

END 



Fig. 2. A formal representation of the class Bag 



model the attributes of class Bag. The INVARIANT clause declares them to be functions 
mapping object identities to attribute values. All variables are initialized to the empty 
set, because, upon system startup, no instances of Bag exist. 

Constructors and destructors of objects are defined as B operations. The return value of 
the constructor newBag is an instance of the class. This instance is nondeterministically 
chosen from the set BAG - bag. A constructor may have parameters for setting attribute 
initial values, such as bnd in the example. 

A class diagram usually specifies just the signature of a method but not its functionality. 
Therefore, we augment the B specification of operations modeling methods by precon- 
ditions and generalized substitutions. For the methods get, and put, those are the parts 
shaded gray in Fig. 2: for get, we nondeterministically choose an element ii of the bag 
oo, return that element and reduce the number of ii in bag oo by one; for put, we extend 
the number of elements ii in oo by one. The precondition elements{oo){ii) < maxint 
is necessary, because the set NAT is the finite interval from 0 upto maxint. 

Inheritance. We simulate inheritance in B according to the idea that an object of a 
subclass is an object of its ancestor classes and that the set of objects of a subclass is a 
subset of the set of objects of its superclass. We generate an abstract machine for each 
subclass. That abstract machine uses the same set of possible object instances as the 
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MACHINE Dynamic^ag 

USES 

Bag 

VARIABLES 

dynamic_Bag 

INVARIANT 

dynamic-Bag C hag 

INITIALISATION 

dynamic_Bag 0 

OPERATIONS 

addDynamic^ag{new) — 

pre 

new G BAG — bag 

then 

dynamic^ag ; = 
dynamic^ag U {new} 

end ; 

supprDynamic-Bag{oo) = 

pre 

oo C dynamic^ag 

then 

dynamic_Bag : — 
dynamic-Bag — oo 

end : 

END 



MACHINE Static_Bag 

USES 

Bag 

VARIABLES 

static-Bag , 
sizeSB 

INVARIANT 

static_Bag C hag A 

sizeSB £ static-Bag — > NAT 

INITIALISATION 

static _Bag, sizeSB 0 , 0 

OPERATIONS 

addStaticJag{new) — 

pre 

new G BAG — bag 

then 

static^ag \ — 
static^ag U {new} || 
sizeSB{new) 0 

end ; 

supprStatic^ag{oo) — 

pre 

oo C static_Bag 

then 

static-Bag : — 
static^ag — oo \\ 
sizeSB oo ^ sizeSB 

end ; 



END 

Fig. 3. A formal representation of subclasses Dynamic-Bag and Static-Bag 



machine representing its superclass. The set of existing instances of the subclass is a 
subset of the one of the superclass. New attributes of the subclass are modeled as before 
by binary relations between the set of existing instances and the types associated to the 
attributes. 

Figure 3 shows the formalization of the subclasses Dynamic-Bag and Static-Bag of Bag 
(c.f. Fig. 1). The variables dynamic-Bag and static-Bag are the instance variables of the 
two classes. They are subsets of bag, which is visible in the machines representing the 
two classes, because they refer to the machine Bag by a USES clause. Thus, they have 
read-only access to the variables of Bag. The variables of the used machine may be 
referred to in invariants and in operation specihcations. 

However, the B notation does not allow a machine to change the state of a machine it 
uses. This is possible for a machine that INCLUDES another one. In contrast to the USES 
construct, a machine may only be included by at most one other machine. Therefore, 
neither construct alone is suited to model subclasses by referring to a machine that 
modeles their (common) superclass. 

Figure 4 shows the hierarchy of B machines that modeles the inheritance hierarchy of 
Fig. 1. Each class gives rise to an abstract machine, the superclass machine {Bag) is 
used by all its subclass machines (Static-Bag, Dynamic-Bag). These machines are all 
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Fig. 4. Machine hierarchy modeling the subclasses of Bag 



included in the top-level machine called BagJnterface that declares the interface of all 
objects belonging to one of the classes of the inheritance hierarchy. 

Typically, if a machine is refered to in a number of specification machines, then they 
should all be included (by INCLUDES) in another one. The operations of included ma- 
chines are not regarded as operations of the including machine. They can, however, be 
promoted (by the clause PROMOTES) to become operations proper of the including 
machine. Those visibility rules of B machines ensure that the consistency of the con- 
structions in a B specification can be checked by relatively simple verification conditions. 
Those rules force us, however, to distribute the formalization of methods over several 
machines, and to model late binding by dispatching in a top-level “interface machine”, 
as we will explain in the following. 

The methods of all classes of our example inheritance hierarchy are accessible via the 
interface machine shown in Fig. 5. To model inheritance, we must revise the definition of 
the constructor newBag (c.f. Fig. 2): We split that definition into two. One called addBag 
replaces newBag in the machine Bag. It adds an object to the set of existing instances 
of bags and initializes its attribute values. The second is the definition of the constructor 
newBag, which now resides in the interface machine. It nondeterministically chooses 
the object instance new to be created and calls addBag. With that mechanism, we can 
create a new instance of the class Bag as well as one of a subclass as a specialization of 
Bag. The operations newDynamicBag and newStaticBag accomplish this. 

We must also modify the definitions of operations representing methods such as put and 
get which are inherited and possibly redefined by the subclasses. We add the name of the 
class as a suffix to the names of the operations in the machines defining the functionality 
of the single classes (putJbag, put_staticJbag, etc.). In the interface machine, we define 
new operations put and get, which call the other operations according to membership of 
the parameter object oo in one of the instance sets. Thus, we simulate late binding by 
explicitly dispatching operation calls in the interface machine. 

In general, operation definitions must to be put either in the interface or in the machine 
defining the class, depending on the state variables that need to be modified. Operations 
are defined in the machine defining the class if the variables they modify are declared in 
this machine; operations modifying variables of other machines must be defined in the 
interface machine. For example, chg_bound and get_staticJ>ag are defined in the inter- 
face because they modify two variables of the subclass and of the superclass. In contrast. 
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MACHINE Bag Jnterface {ELEMENT) 

INCLUDES 

Bag(ELEMENT) , 

Dynamic_Bag, STatic_Bag 

DEFINITIONS 

get_siaticJyag{oo) = 
put_sraticJ?ag{oo, ii) = | . . . | 

OPERATIONS 

oo < newBag{hnd) — 

pre 

bnd G NAT A 
not{BAG — bag) 

then 

any new where 

new G BAG — bag 

then 

addBag{new, bnd) || 
oo new 

end 
end : 

oo < newDynamic^ag(bnd) — 

pre 

bnd G NAT A 
not{BAG — bag) 

then 

any new where 

new G BAG — bag 

then 

addBag{new, bnd) || 
addDynamic^ag{new) || 
oo ;= new 

end 
end ; 

oo ■{ — newStatic^ag(bnd) — . 

rmvBag{oo) — 

pre 

oo C bag — {dynamic-Bag 
U static^ag) 

then 

supprBagioo) 

end; 



rmvDynamic_Bag(oo) — 

pre 

oo C dynamic^ag 

then 

supprDynamic_Bag{oo) || 
supprBag{oo) 

end; 

rmvStatic_Bag{oo) — ... 

put{oo, ii) = 

pre 

oo G hag A 

ii G ELEMENT A 

elements{oo){ii) < maxint 

then 

if oo G static^ag then 

put_bag{oo, ii) || 

piitjftaticJbagipo^ ii) 

else 

put-hag{oo, ii) 

end 

end; 

elt < — get{oo) — 

pre 

oo G bag 

then 

if oo G static^ag then 
get_staticJbag{oo) 

else 

elt ■< — get_bag{oo) 

end 
end ; 

chg-boimd{oo, ii) — 

pre 

oo G dynamic_Bag A 

ii £ NAT A 

ii > bound{oo) 

then 

chg^tateJyag{oo , elements{oo), ii) 

end; 

END 



Fig. 5. Interface machine of the Bag inheritance hierarchy 
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1. y bg.{bg £ bag ^ ^ ELEMENT \ elements{bg){xx)) < bound{bg)) 

2. \/ oo.{oo ^ static^ag =>■ G ELEMENT \ elements{oo){xx)) — sizeSB{oo)) 

Z.dynamic-Bag H static-Bag — 0 

Fig. 6. Additional invariants for bags 



putJbag is defined in the machine Bag, because it only changes the variables of this ma- 
chine. The operation chg_bound refers to an operation called chg_stateJ)ag that sets the 
attribute values of a bag to the values of its actual parameters. That operation, and others 
to change the attributes defined on other B machines are internal operations. We need 
them to provide a means of changing attribute values by operations that are not defined 
in the B machine that declares the state variables representing those attributes. Because 
the specifications of those “change state” operations are just parallel assignments, we 
do not show them in the figures. 

Constraints. Additional properties that restrict the semantics of one or more elements 
of the UML model can be added in the B specification. They are expressed as predicates 
in the invariant clause of either the interface machine or the class machine. Again, which 
machine is the appropriate place to put them depends on the variables they need to refer 
to. 

Figure 6 shows some of the constraints we used to augment the model derived from the 
UML diagram. The first one is defined in the machine Bag and restricts the numbers 
of elements of a bag to be smaller than its bound. The second constraint is specified in 
the Interface machine and forces the number of elements of a staticJrag to be strictly 
equal to its size. The third one is formalized in the Interface machine and requires the 
specializations static -bag and dynamic Jrag to be disjoint. 

As a consequence of augmenting the model with those properties, we need to strengthen 
the preconditions of several operations such that they are guaranteed to establish those 
constraints as invariants. The figures in the following sections show some of the properties 
we had to add to the Bag model. 



4 Behavioral Conformance I: Data Refinement 

Translating UML class hierarchies to B models and augmenting them with behavioral 
specifications, we provide a formal basis to semi-automatically prove properties of the 
classes in the hierarchy. In the present and the following section, we show how to use 
the B method and the tool AtelierB to prove behavioral conformance in a gen / spec 
hierarchy (c.f. Sect. 2). In doing so, we face two problems; first, we must provide a defi- 
nition of behavioral conformance in terms of the B language; second, we must find a way 
to make AtelierB generate proof obligations that are sufficient for showing behavioral 
conformance. In the present section, we focus on the first condition of behavioral confor- 
mance, namely data rehnement. Section 5 deals with the proof obligations concerning 
history constraints. 
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4.1 Data Refinement in B 

The definition of behavioral conformance in [15] is based on the classical notion of data 
refinement for Z [18], i.e. it is a forward simulation based on Z-style relational pre- and 
postcondition specifications of operations. More formally, a class C data refines a class A 
if there exists a relation CI{c, a), the coupling invariant between the states c of instances 
of C and the states a of instances of A such that the following conditions hold for op: 

- the initialization of C is sufficient for the initialization of A 

Vc. CInit{c) {3 a. CI{c, a)AAInit{a)) 

and for each pair of operations opa and opc which are the respective specifications of 
the same method in A and C, respectively: 

- the precondition of opa is sufficient for the precondition of opc 

'i a,c. [pre opa){a)/\CI{c,a) => [pre opc){c) 

- each concrete state transition has an abstract counterpart 

^ a,c,c' .{pre opa){a)ACI{c, a)Aopc{c, c') {3a'. CI{c' ,a')Aopa{a,a')) 

Here, the precondition {pre op) {s) of an operation specification is defined by 
{pre op){s) 

The refinement of B machines [1] is defined in the semantic framework of set transfor- 
mers, which are isomorphic to predicate transformers. Relational forward simulation can 
be considered as a special case of data refinement in a predicate transformer setting [6]. 
Therefore, it is plausible^ that proving the refinement of properly defined B machines is 
an adequate basis to prove the data refinement condition of behavioral conformance. 

4.2 B Machines for Data Refinement 

According to the B method [1], each way of constructing a B abstract machine (from 
scratch, by including another, by refining another, etc.) comes with a number of proof 
obligations that are sufficient for the consistency of the entire model. For each operation, 
for example, we must prove that it preserves the state invariant of the machine in which 
it is defined. If we construct a machine from a given one by a REFINEMENT, then 
this implicitly defines a B machine that is supposed to be a data refinement of the 
base machine. Processing such a refinement definition, AtelierB will generate proof 
obligations that are sufficient for a data refinement (see [1] for the theory justifying 
those conditions). 

For representing a UML gen / spec hierarchy in B, we do not directly use refinement of 
B machines (c.f. Fig. 4), because if safe use of polymorphism is not an issue, then the 

^ We do not attempt to present a formal proof here, because that would exceed the limits of this 
paper. 



Behavioral Conformance Verification in an Integrated Approach 



369 



MACHINE Operation Jiefinement_Bag_Put{ELEMENT) 

INCLUDES BagJnterface{ELEMENT) 

OPERATIONS 

Operation-Bag-Put{oo , ii) — 

pre 

oo G bag A 
ii G ELEMENT A 

xr.(xv G ELEMENT \ elements{oo){xx)) < bound{oo) A 
elements {oo){ii) < maxint 

then 

putJyag(oo, ii) 

end 



END 

REFINEMENT Operation Jiefinement_Static^agJ^ut{ELEMENT) 

REFINES Operation Jiefinement_Bag_Put 
INCLUDES concrete. Bag Jnterface{ELEMENT) 

INVARIANT 

concrete. bag = hag A 
concrete. elements — elements A 
concrete .bound — bound A 

OPERATIONS 

Operation^ag-Put{oo , ii) — 

pre 

oo G concrete. static_Bag A 
ii G ELEMENT A 

jo:.(xx G I concrete. elements{oo){xx)) < concrete. hound(oo) A 

concrete. elements{oo){ii) < maxint 

then 

concrete .put{oo , ii) 

end 



END 



Fig. 7. Operation verification for Put 



specializations in such a hierarchy need not hehaviorally conform to the general class. 
Therefore, to analyze behavioral conformance in a class hierarchy, we define auxiliary B 
machines whose associated proof obligations are the ones we wish to prove for behavioral 
conformance. 

To prove the data refinement condition between two classes A and C, we need not consider 
the initialization condition explicitly: Because we construct a specialization C from the 
machine representing the general class A (c.f. Fig. 4) by USES clauses, the initialization 
of C by definition includes the initialization of the general machine representing A. 
Addressing the refinement of operations, we construct two B machines for each operation 
op of the more general class A. The first machine defines an operation for the abstract 
version of op. The second machine is a rehnement of the first, using the version of C for 
op. For example, to prove the data rehnement condition for Bag and StaticBag and the 
operation put, we dehne the two machines shown in Fig. 7. 
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The first machine defines Operation JiagJ’ut, which basically calls the definition of 
put in class Bag, which is putJbag. It is based on the interface machine BagJnterface. 
Directly including the machine Bag is impossible, because a machine may be included 
by at most one other machine and BagJnterface already includes Bag. If we included a 
copy of Bag, however, then we would get a type checking error, because the declaration 
of the base set BAG of object identifiers (c.f. Fig. 2) would be duplicated. 

Refining the first machine, the second includes a copy of BagJnterface called concrete. 
The coupling invariant for the refinement identifies all state components of concrete with 
the ones of the original BagJnterface. Unless the mathematical model of the data in the 
specialization differs from the one of the more general class, the coupling invariant in 
an object-oriented setting usually is just a projection from the state of the specialization 
(which may have additional attributes) to the state of the more general class [15]. We 
redefine the operation Operation JiagJ’ut in the second machine to call the version of 
put of Static Jiag. We achieve this by stating the precondition oo G concrete .static Jiag 
and calling concrete.put in the body of the operation. As before, the predicates shaded 
gray describe information not present in the UML model: To sucessfully augment a bag 
with an element, the number of elements already present in the bag must be strictly 
less than the bound of the bag. The refinement conditions AtelierB generates for that 
pair of machines are exactly the ones needed to prove the conditions of data refinement 
concerned with the operation put. 

For the other operations of Bag, we construct similar pairs of machines to relate them to 
the ones of Static Jiag. Conceptually, we could define only one pair of machines including 
all the necessary operation definitions. We prefer to define many small machines to keep 
the single machines more accessible and facilitate change. Those machines are not used 
further because they are constructed only to generate appropriate proof obligations for 
data refinement. Therefore, they do not clutter any further use of the classes in the gen / 
spec hierarchy. 



5 Behavioral Conformance II: History Constraints 

Mapping the concept of history constraints into the framework of B, we must take two 
kinds of proof obligations into account (c.f. Sect. 2). First, we must find a place to 
specify history constraints of a class, and verify that each class specification - made up 
of a number of B machines - is history consistent. Second, we must verify that history 
constraints are preserved along gen / spec relations. 



5.1 History Consistency 

To specify the history constraints of a class, we define a machine that includes the 
interface machine of the class hierarchy we consider. Figure 8 shows that machine for 
the class Bag. The predicate HC is the history constraint of Bag. The history of BAG 
is unconstrained, because HC is equivalent to true. The syntactic form of HC serves 
to illustrate how the history constraint depends on the values of the attributes before 
and after a state transition. Given that history constraint of Bag, the extra methods of 
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MACHINE Histoty^ag{ELEMENT) 

INCLUDES 

BagJnterface{ELEMENT) 

DEFINITIONS 

HC{previousE. previousB. nextE, nextB) = 

{previousE — nextE V not{previousE — nextE) A 
{previousB — nextB V not{previousB — nextB))) 



OPERATIONS 

history{oo) — 

pre 

oo G bag 

then 

any newb,newe where 

newe G ELEMENT > nat A 

newb G nat A 

I newb > ^ XX. (xr £ ELEMENT \ newe{xx)) A 

HC{elements{oo ) , boimd{oo ) , newe, newb) 
then 

chg^tate{oo, newe, newb) 

end 

end 



END 



Fig. 8. History specification for Bag 



a specialization of Bag, such as Dynamic-Bag, may perform arbitrary state changes 
(within the limits of the class invariant) without destroying behavioral conformance. 
The machine History_Bag defines one operation history that changes the state of the 
parameter object oo nondeterministically within the restrictions specified by the history 
constraint: It selects new values newb and newe of the attributes {bound and elements) 
of oo such that the relation HC holds between those new values and the given values of 
the attributes of oo. Then it changes the attribute values of oo with the internal operation 
chg_state, which is defined in BagJnterface. Thus, the precondition of the operation 
history is /(i)A(3 s' . HC{s, s')). The state transition relation of history is HC. 



Verification. To verify history consistency, we need to verify the proof obligations men- 
tioned in Sect. 2 for each operation of the class. The first condition, I{s)AHC{s, s') 

I (s'), is one of the proof obligations associated with the definition of the machine 
HistoryJ3ag\ The operation history must respect the invariant of BagJnterface. Be- 
cause the transition relation of history is HC, we get exactly the proof obligation we 
wish to prove. 

For the second condition, I{s)AI{s')AOp{s, s') HC{s, s'), we define a refinement of 
the machine History Jiag for each operation of Bag. Figure 9 shows the one for put. 
In that refinement, we use the proof obligations for operation refinement to formalize 
the condition of history consistency: In Sect. 2, we mentioned that we may consider the 
history constraint as an anonymous operation that is refined by all (named) operations 
of the class. Therefore, the refined version of the operation history (in Fig. 9) calls the 
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REFINEMENT History_Bag_Put(ELEMENT) 

REFINES HisroryJag 

INCLUDES 

New.BagJnteiface{ELEMENT) 

INVARIANT 

New. hag — bag A 

New. elements — elements A 

New. bound = bound A 

OPERATIONS 

history{oo) — 

pre 

oo G New. hag 

then 

any n where 

U G ELEMENT A 

^ xc.(ax G element \ New.elements{oo){xx)) < New.bound{oo) A 
A^ew.e/eme«f5(oo)(//) < maxint 

then 

end 

end 



END 



Fig. 9. History consistency of put 



operation put (of Bag) with an arbitrary input parameter ii satisfying the precondition 
of that operation. 

The first condition of operation refinement (c.f. Sect. 4.1) considers the preconditions. 
It is satisfied because the precondition of the concrete operation is not stronger than the 
one of the abstract operation (the latter is just the invariant). 

The second condition of operation refinement considers the transition relations. For 
the abstract operation, the transition relation is given by the history constraint H. By 
construction, the coupling invariant of the refinement is equivalent to the equation c = a. 
Using the one point rule, we calculate 

iy a^c,c' .(pre opa){a)/\Cl{c,a)/\opc{c,c') (3a'. CI(c' ,a')/\opa(a,a'))) 

(V a, c, c' .c = aAopc(c, c') => (3 o', c' = a'AHC(a, a'))) 

4A (\/c,c'.opc(c,c')=AHC(c,c')) 

In our example, we get: 

( V elements^ bound, New .elements , New. bound, N ew. elements' , New. bound' , . . . . 
(pre history a(oo))(elements , bound) 

ANew .elements = elements ANew .bound = boundA . . . 

Ahistory c(oo) (New. elements. New. bound. New. elements' , New. bound') 

=> (3 elements' , bound ' , .... 

New .elements' = elements' ANew. bound' = bound' A . . . 

A(historya(oo)) (elements, bound, elements' , bound')) ) 
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( V elements, bound, elements' , bound ' , .... 
put{oo, ii){elements, bound, elements' , bound') 

HC {elements, bound, elements' , bound') ) 

Again, for lack of space, we cannot formally derive that equivalence from the semantics 
of the involved B machines in this paper. The derivation involves reducing the operation 
definitions to set transformers, and deriving the preconditions and transition relations for 
the resulting transformers. The general theory for doing so is elaborated in [1]. Note that 
the preconditions of both versions of history require that oo € bag and that the invariant 
holds, but they are independent of HC. 

To completely verify history consistency of the class hierarchy shown in Fig. 1, we must 
construct “history machines” as the one of Fig. 8 for all classes of the hierarchy, and we 
must construct refinements similar to the one shown in Fig. 9 for all operations of those 
classes. The history constraint Static Jiag is non-trivial, because it requires that bound 
does not change: 

HC{previousE, previousB, nextE, nextB) = 

{previousE = nextE V not{previousE = nextE) A 
{previousB = nextB))) 

Proving that Static Jiag is history consistent, we show that none of the operations of that 
class changes the bound of its parameter object. 



5.2 History Preservation 

Having shown that all classes of the gen / spec hierarchy of Fig. 1 are history consistent, 
and knowing that DynamicJiag and Static Jiag data refine Bag, it remains to show that 
the two specializations of Bag preserve the history constraint of Bag. Remember from 
Sect. 2 that the second condition of behavioral conformance requires us to show that the 
history constraint of DynamicJiag and Static Jiag each imply the history constraint of 
Bag. 

In terms of predicate logic, we just wish to prove two implications of the form He ^ Hg. 
Technically, we are faced with the problem of encoding the history constraints in related 
B machines for which the B method requires prove obligations that are equivalent to 
that simple implication. As for verifying history consistency in the previous section, we 
use refinements of B machines to reach that aim. 

For Bag, we again use the machine HistoryJiag (c.f. Fig. 8). To verify history preser- 
vation of DynamicJiag with respect to Bag, we define the machine shown in Fig. 10. 

The definition of HC in that machine shows the history constraint of DynamicJiag, 
which requires that the bound must not decrease. As before, the operation history is 
constructed in such a way that its transition relation is given by the history constraint. 
The coupling invariant also is just a conjunction of equations identifying the states of 
the two copies of BagJnterface. Therefore, with a calculation similar to the one of 
the previous section, we verify that proving the refinement conditions for the operation 
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REFINEMENT History_RefinementJ)ynamic_Bag{ELEMENT) 
REFINES History_Bag 

INCLUDES 

New.BagJnteiface {ELEMENT) 

DEFINITIONS 

HCipreviousE. previousB. nextE, nextB) = 

{previousE — nextE V not{previousE — nextE) 
A {previousB < nextB)) 



INVARIANT 

New. hag — bag A 

New. elements — elements A 

New. hound — bound A 

OPERATIONS 

history{oo) — 

pre 

oo G New .dynamic^ag 

then 

any newb, newe where 

newe G ELEMENT ¥ nat A 

newb G nat A 

newb > ^ -o:.(xx G ELEMENT \ newe{xx)) A 

HC{New.elements{oo) , New .bound{oo ) , newe., newb) 

then 

New.chg_state{oo, newe, newb) 

end 

end 

END 



Fig. 10. History preservation of Dynamic-Bag wrt. Bag 



history amounts to proving the implication between history constraints that we wish to 
prove. 

There is, however, a grain of salt in this argument: The precondition of the abstract 
version of history in Fig. 8 is not sufficient for the precondition of the “refinement” of 
history in Fig. 10. That condition essentially requires that all bags are dynamic bags: 

00 € bag oo £ dynamic-Bag 

That implication obviously is not true. Conceptionally, our reasoning is nevertheless 
sound, because the relation between the classes Bag and Dynamic-Bag is important only 
for instances of the specialization Dynamic Jiag. For other instances of Bag (e.g. static 
bags) that are not instances of Dynamic J3ag, the question whether DynamicJiag beha- 
viorally conforms to Bag is not of interest. 

Technically, there are two ways of resolving that problem. First, we could change the 
precondition of history in the abstract machine HistoryJiag to oo £ dynamic Jiag. 
But then, the resulting machine could serve only for proving behavioral refinement of 
Bag by Dynamic-Bag. For StaticJiag, we would have to use a copy of History_Bag with 
precondition oo £ staticJiag. In general, we would have to construct a new “history 
machine” of the more general class for each proof of behavioral conformance in which 
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that class is involved. All those machines would differ only in the precondition of the 
operation history. 

Second, we could take a pragmatic view and just accept that the refinement condition 
for preconditions is not provable when we verify history preservation. This is what we 
currently do. It spares us the effort to define (and manage) different versions of “history 
machines” for a single class. It also reduces the proof load for AtelierB. We believe 
that this procedure is still safe, because an attempt to prove a false implication between 
history constraints manifests itself in the condition on the transition relations and not in 
the condition on the preconditions. 



6 Experience 

In the present section, we give an impression of the size of the B model that we have 
derived from the UML model in Fig. 1 . We also discuss how verifying B models with 
the tool AtelierB compares to proving in a model of object oriented specifications [15] 
that we have developed for Isabelle/HOL [13]. 

The complete B model of the gen / spec hierarchy of bags comprises 21 components 
in B (abstract machines or refinements). Table 1 shows a statistics about the proofs we 
conducted on those components. The components written in italics stem from translating 
the UML model to B. The ones written in bold face serve to verify behavioral confor- 
mance. The column Obv shows the number of obvious proof obligations the B method 
requires for each component, the column nPO stipulates the number of proof obligati- 
ons that are not “evident”, i.e. immediately discharged by AtelierB without invoking a 
proven The column nUn presents the number of unproved proof obligations, and % Pr 
shows the percentage of discharged obligations. The two unproven obligations are the 
false implications between preconditions that we discussed at the end of the preceeding 
section. 

Table 1 illustrates that the part of the B model representing the UML model is relatively 
small: it comprises 5 machines for the three classes; the machine Types is a quite small one 
containing a few global declarations of sets to which the other machines refer. The other 
16 machines are constructions supporting the verification of behavioral conformance. 
While that may seem quite a large number, the important fact to note is that those 
machines can be derived from the others automatically, and that they are used solely 
in the verification of behavioral conformance. A UML model that uses the hierarchy of 
bags does not need to consider those machines. 

As a tool specialized for the B language and method, AtelierB provides a quite elaborate 
interface for working with B models. All proof obligations are set up fully automatically. 
The ones that are not “evident” are presented to the user for interactive proof. With a few 
proof commands, users who do not have extensive experience with general purpose pro- 
vers can still conduct substantial proofs. In our experience, the performance of AtelierB 
is quite satisfactory. 

These observations are valid as long as the B models refer to the parts of the underlying 
mathematical theory that are often used and, therefore, well-supported by the tool. When 
we used to summation operator ^ to express properties of the bound on the elements 
of bags, it became evident that other parts of the theory are not sufficiently supported by 
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Table 1. Proofs results for the bag hierarchy specification 



COMPONENT 1 


Obv nPO nUn % Pr 


Bag 


15 


26 


0 


100 


BagJnterface 


87 


46 


0 


100 


Dynamic Jag 


3 


0 


0 


100 


History_Bag 


40 


0 


0 


100 


History _Bag_Get 


14 


6 


0 


100 


History Bag Put 


17 


6 


0 


100 


History _Dynamic_Bag 


20 


2 


0 


100 


History _Dynamic_Bag_Chg_bound 


15 


3 


0 


100 


History JJynamicJJag Get 


13 


7 


0 


100 


History _Dynamic_Bag_Put 


16 


7 


0 


100 


History _Reflnement_Dynamic_Bag 


50 


79 


1 


99 


History JieflnementStaticJJag 


36 


41 


1 


98 


History _Static_Bag 


20 


2 


0 


100 


History _Static_Bag_Get 


11 


7 


0 


100 


History Static BagJ*ut 


14 


7 


0 


100 


Operation_Reflnement_Bag_Get 


6 


0 


0 


100 


Operation_Reflnement_Bag_Put 


6 


0 


0 


100 


Operation Refinement Static_Bag Get 


9 


11 


0 


100 


Operation_Refinement_Static_Bag_Put 


13 


8 


0 


100 


Static_Bag 


3 


8 


0 


100 


Types 


1 


0 


0 


100 


TOTAL 


409 


266 


2 


99 



AtelierB. Properties of ^ such as 
V(A,x). ^ x.{x £ A I 0) = 0 

for some finite set A are not part of the set of rules used hy AtelierB. This property is not 
derivable using the implemented set of rules. Therefore, we assumed this and three other 
properties of ^ for the proofs in AtelierB. The only way to make use of those properties 
in the proofs is to interactively specialize the universal quantifiers. It is impossible to 
introduce new rules that can be applied automatically during proofs, because those rules 
are all hand-coded into the implementation of the proven 

To make sure that we did not introduce an inconsistency in our theory, we derived those 
properties of ^ in Isabelle/HOL. There, we have a theory supporting the Z mathematical 
toolkit, whose definitions are quite similar to the ones used in B. 

Compared to working with AtelierB, proving theorems in Isabelle tends to be more in- 
teractive. This is mostly because the automated support for the Z toolkit is not developed 
as far as the one implemented in AtelierB. It is, however, very easy to extend the theory 
by new theorems, and make the proof tactics, such as the simplifier, use those theorems 
automatically. This clearly is an advantage of a proof engine like Isabelle that is designed 
to be modified and extended. 

There also is another difference between the two tools: The theory we have developed to 
support object oriented specification [15] allows us to derive theorems about relations of 
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classes in general, which we may specialize for concrete classes later (without having to 
reprove the theorem). Thus, we could derive mechanically that behavioral conformance 
is transitive. AtelierB does not allow us to conduct similar proofs about B machines in 
general. Thus, we cannot establish a theory in AtelierB that would allow us to conclude 
that, e.g., a behaviorally conforming specialization of static bags also is a behaviorally 
conforming specialization of bags. Instead, we would have to prove behavioral confor- 
mance with respect to bags directly. For the small hierarchy of classes that we considered 
in this paper, the effort involved in those proofs is not an issue, but for a large hierarchy, 
the effort of conducting redundant proofs would quickly become unbearable. For such 
a task, a more open tool environment for B is desirable that would allow for extending 
proof procedures and defining new verification conditions for particular contexts. 



7 Conclusions 

We are not the first to propose a combination of UML (or OMT) notations with a formal 
technique. Others have studied integrations of OMT and LOTOS [20], OMT and VDM 
[4], and UML and Z [3]. The following research more specifically addresses translating 
models of the UML to B specifications: 

- Nagui-Raiss [12] proposes a translation from extended entity association diagrams 
to B. 

- Shore [16] presents an alternative method for producing formal specifications from 
objects. The approach taken here represents the object structure at the implementa- 
tion level by abstractly representing objects as structures (in B) at the machine level 
that are refined during a development using machines representing those objects. 

- Facon et al. [5] define rules from both OMT static and dynamic models to B specifi- 
cations. They are interested in modularizing the formal specification resulting from 
the object model transformation. 

- Lano [7,8] illustrates the use of object-oriented methods to support the development 
process in B. He proposes several translations to map analysis models of OMT to 
B machines. 

Compared to that research, our approach is novel in that we use the framework of B 
to verify properties of class hierarchies such as behavioral conformance, which may 
or may not be expressed in the UML model. Constructing B components in an appro- 
priate way, we utilize the verification conditions that the B method associates with those 
components to verify properties that stem from an object oriented world and are not ge- 
nuinely properties one would verify of a B model made up from scratch. An advantage 
of that approach is not only that we can rely on the theoretically well understood formal 
framework of B, but also that we can use a tool such as AtelierB to generate and verify 
the properties we wish to show about the UML model. Building on AtelierB, we set 
up a productive working environment for generating and proving the proof obligations 
that stem from the object oriented world in a very short time. Implementing a tool from 
scratch to support the same tasks would have taken much longer, and it would have been 
much more error prone. Although AtelierB has its deficiencies in terms of robustness. 
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extensability and openness, it relieved us from many routine tasks that take much ef- 
fort to implement, such as tracking dependencies between assertions, and recording and 
mainting proofs. The construction of auxiliary B machines to generate appropriate proof 
obligations may seem complicated, but it surely is much simpler and much more safe 
with respect to soundness of the logical derivations than implementing a tool that would 
produce and prove them directly. 

The translation from an UML class diagram to a system of B components can be au- 
tomated to a large extent. We are currently working on an implementation that will 
automatically carry out the construction of B machines illustrated in this paper. To date, 
we augment the B model resulting from such a translation with behavioral descriptions 
of operations and with properties expressing invariants, preconditions, and history con- 
straints. Most of those could be expressed by constraints in a formal language such as 
OCL within the UML model. If a particular formal notation for expressing constraints 
of a UML model will he widely accepted in the future, it will be easy to provide a trans- 
lation from that language to B. For now, we do not see it as a heavy burden for specifiers 
to express formal constraints directly in B. 
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Abstract. We define a class of diagrams that represent abstractions of — possibly 
infinite-state — reactive systems described by specifications written in temporal 
logic. Our diagrams are intended as the basis for the verification of both safety 
and liveness properties of such systems. Non-temporal proof obligations establish 
the correspondence between the original specification and the diagram, whereas 
model checking can be used to verify properties over finite-state abstractions. We 
describe the use of abstract interpretation techniques to generate proof diagrams 
from a given specification and user-defined predicates that represent sets of states. 



1 Introduction 

Verification techniques for reactive systems are traditionally classified as either deductive 
or algorithmic. Whereas deductive verification can in principle establish properties of 
arbitrarily complex systems, algorithmic verification such as model checking is usually 
restricted to finite-state systems, although some classes of infinite-state systems have 
been identified for which certain properties are decidable. On the other hand, algorith- 
mic verification is (essentially) automatic and, hence, easy to use by system engineers, 
whereas computer support for deductive verification in the form of interactive proof as- 
sistants requires careful guidance by experienced users. Combinations of both kinds of 
technique such as deductive model checking have also been suggested, with the aim of 
providing a unified framework that combines the advantages of deductive and algorith- 
mic verification. More generally, abstraction and composition have been recognized as 
the key concepts that bridge the two approaches [13,9]. Our paper proposes the concept 
of predicate diagrams to integrate algorithmic and deductive verification techniques; it 
allows to relate specifications and properties by constructing an abstract finite model. We 
consider safety as well as liveness properties by annotating diagrams with information 
relating to fairness and ordering conditions. We also show how predicate diagrams can 
be constructed semi-automatically, based on techniques of abstract interpretation. 
Predicate diagrams intend to help users to understand how a reactive system (or a distri- 
buted system) is working. We have focused on defining a framework that is as powerful 
as traditional deductive verification and can integrate safety, fairness, and general liven- 
ess properties, yet can abstractly represent the given system at a level that is intuitive to 
understand for the system designer. We have applied predicate diagrams to some case 
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W. Grieskainp, T. Santen, and B. Stoddart (Eds.): IFM 2000, LNCS 1945, pp. 380-397, 2000. 
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studies such as a reader- writer algorithm developed at Siemens Corporate Research [11] 
and a self-stabilizing algorithm due to Dijkstra [26]. On the other hand, an abstract ani- 
mator [4] based on techniques of abstract interpretation has been shown to allow models 
for non-trivial systems to be built automatically once the user has defined the relevant 
abstract predicates. Our method can therefore be seen as a natural generalization of tra- 
ditional model checking, except that it is applied to an abstract state space. In particular, 
there is no need for the user to provide inductive invariants as in deductive verification. 
We assume the system to be modeled as a specification written in a variant of TLA [17] 
and we use the temporal language of linear-time temporal logic for stating required 
assertions or properties. Nevertheless, the basic ideas that underly our approach ap- 
ply more widely. We define verificafion conditions that ensure that a predicate diagram 
adequately represents a system specification; these verification conditions must in ge- 
neral be discharged using an automatic or interactive theorem proven The second task 
is to show that every run of the diagram satisfies the asserted properties. Because pre- 
dicate diagrams are finite, this can be established using standard model checkers such 
as Spin [12], obviating the need for tedious temporal reasoning that plagues standard 
deductive verification. We have shown that the constructions of the diagram can often be 
automated using abstract interpretation. The user need then only choose the predicates 
that define the abstraction function. Besides their use as a formal basis for verification, 
predicate diagrams can also serve as support for explaining how systems are working 
and for documenting them. 

Using diagrams to simplify, to visualize or to structure a proof is not new. There are 
many works like proof diagrams proposed by Manna et al [7,22,23], predicate-action 
diagrams from Lamport [18], proof lattices proposed by Lamport and Owicki [27] and 
proof charts proposed by R. Cousot [5]. 

The contributions of our work are the following: 

- We emphasize a clear separation of concerns and identify those subtasks that are 
within the realm of, respectively, theorem proving and model checking. 

- Following ideas present in [25,14], edges of a predicate diagram can be labelled by 
well-founded orderings to exclude runs where such an edge is taken infinitely often; 
we can thus prove liveness properties (these annotations simulate the lattice rule of 
temporal logic). 

- Fairness assumptions about transitions can be stated on the level of diagrams; these 
assumptions are taken into account when proving liveness properties using model 
checking. 

- We propose an automatic construction of a predicate diagram by using abstract 
interpretation. This construction may require approximations introduced via maybe 
edges, and we propose solutions to eliminate such maybe edges via a reconsideration 
of the corresponding transitions at the concrete level. 

The paper is structured as follows. Section 2 presents predicate diagrams. Section 3 
describes the relationship between specifications and predicate diagrams. Sections 4 
and 5 explain how we use abstract interpretation to construct a predicate diagram for 
a given specification. Sections 6 and 7 compare with related works and conclude the 
paper. 
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2 Predicate Diagrams 

We express system specifications and properties in a variant of linear- time temporal logic 
whose formulas are built from state predicates and actions, which may contain primed 
state variables. For example, a; > 3 is a state predicate, and x < y'+l is an action. For 
an action A, we denote by enabled A the state predicate obtained from A by existential 
quantification over the primed state variables. For a state predicate P, we denote by P' 
the action obtained from P by replacing all flexible variables vhy v' . Temporal formulas 
are formed using boolean connectives, the always operator □, and quantification over 
rigid (state-independent) variables. 

The semantics of state formulas is defined with respect to a state, i.e. an assignment of 
values to state variables, and a valuation of the rigid variables. Actions are interpreted 
relative to a pair (s, t) of states, where s and t interpret respectively the unprimed and 
primed state variables. Temporal formulas are evaluated over behaviors, which are w- 
sequences a = sosi ■ • ■ of states [15,24]. We write s \= P, (s, t) ^ A, and a \= F to 
denote that a state predicate P, an action A or a temporal formula F hold of a state, a pair 
of states or of a behavior. Validity of a temporal formula F (over the class of first-order 
interpretations of interest) is denoted by |= F, and similarly for state predicates and 
actions. 

Derived connectives include the eventually operator defined by OF = -iD-iF, the 
leads-to operator F G=n(F =>OG) and, for an action A, the formulas 

WF(A) = (on ENABLED A) DOA 
SF(A) = (DO ENABLED A) DOA 

that assert weak and strong fairness conditions for A. This logic is similar to Lamport’s 
Temporal Logic of Actions [17], but it is not invariant under stuttering.' As in TLA, 
specifications of reactive systems can be expressed as temporal formulas; these are 
usually written in the form IniiAD AezfAL where Init is a state predicate characterizing 
the system’s initial state, Next is an action that represents the next-state relation, and L 
is a conjunction of formulas WF(A) or SF(A). 

We assume the underlying assertion language to contain a finite set O of binary relation 
symbols ^ that are interpreted by well-founded orderings. For -< G O, we denote by ^ 
its reflexive closure. We write to denote the set of relation symbols ^ and A, for A 
inO. 

The definition of predicate diagrams is relative to finite sets V and A that contain the 
state predicates and actions of interest. We denote by V the set containing the predicates 
in V and their negations. 

Definition 1. A predicate diagram G = {N, I,S, o, Q over V and A consists of 

- a finite set N 2^ of nodes, 

- a finite set I C N of initial nodes, 

' Stuttering invariance is unimportant for the verification of some fixed specification. It becomes 
essential when predicate diagrams are used for the top-down development of reactive systems 
by stepwise refinement, a topic to be described in a separate paper. 
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- a family S = {Sa)agA of relations 5 a C N xN, 

- a family o = (oA)AeA of edge labellings oa that associate finite sets {(fi, ^i), ■ ■ • , 
(ik, ^fc)} of terms f paired with a relation -<i G with the edges (n, m) G 5 a, 

- a mapping C : ^ > {NF, WF, SF} that associates a fairness condition with every 
action in A; the possible values represent no fairness, weak fairness, and strong 
fairness. 

We say that the action A G A can be taken at node n G N iff (n, m) G 5 a holds for 
some m G N . 

A predicate diagram G is a finite labelled transition system whose nodes are sets of state 
predicates from V or their negations. Intuitively, a node represents the set of system states 
that satisfy the formulas contained in the node. (In the following, we indifferently write 
n for the set and the conjunction of its elements.) Transitions are labelled by actions and 
by ordering annotations that indicate which terms decrease with respect to relations from 
. An action A may have an associated fairness condition; it applies to all transitions 
in 5a rather than to individual edges. 

We now define traces through a diagram as behaviors that correspond to fair runs sa- 
tisfying the node and edge labels. To evaluate the fairness conditions, we identify the 
enabling condition of an action A G A with the existence of A-labelled edges at a given 
node. 

Definition 2. Let G = {N ,I o,(f) be a predicate diagram over V and A. The set 
tr{G) of traces through G consists of all uo-sequences a = sgsi . . . of states such that 
there exist sequences ngrti . . . and AqAi . . . of nodes Ui G N and actions A^ G A such 
that all of the following conditions hold: 

- uq G I is an initial node, 

- {rii, rii+i) G 5Ai holds for all i G N, 

- Si \= rii holds for all i G N, 

- (si,Si+i) 1= Ai holds for all f G N, 

- (si, Si+i) 1= f' A f holds for all i G N and (f, a) G OAftii, Ui+i), 

- for every action A G A such that C(^) = WF there are infinitely many i G N such 
that either Ai = A or A cannot be taken at Ui, and 

- for every action A G A such that C(^) = SF, either Ai = A holds for infinitely 
many i G N or there are only finitely many f G N such that A can be taken at Ui. 



3 Reasoning about Systems via Predicate Diagrams 

3.1 Relating Specifications and Predicate Diagrams 

We say that a predicate diagram G conforms to a specification Spec, written Spec < G, 
if every behavior that satisfies Spec is a frace through G. In general, proving Spec < G 
requires reasoning about entire behaviors. The following theorem allows us to (essen- 
tially) reduce this temporal reasoning to “local” proof obligations that concern single 
states or pairs of states. 
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Theorem 3. Let G = {N , 1,6, o,Q be a predicate diagram overV and A, and Spec = 
InitAONextAL be a system specification. If all of the following conditions hold, then 
a G tr{G) holds for all models a of Spec. 

1. 1= Init => \J n 

n^I 

2. \= nANext ^ \J AAm' holds for every node n G N . 

3. 1= nAAAm' ^ t' ^ t holds for all A G A, {n,m) € 6 a, and{t,A) € OA{ti,m). 

4. For every action A G A such that C(^) NF; 

a) IfC{A) = WF then \= Spec => WF(vl). 

b) IfC,{A) = SF then |= Spec SF(^). 

c) ^ n => ENABLED A holds whenever A can be taken at node n. 

d) ^ uAA => -im' holds for all n,m G N such that {n, m) ^ 6 a- 

Proof. Assume that Spec and G are such that all the conditions hold, and assume that 
a = sosi • ■ • is a behavior that satisfies Spec. In order to show that a G tr{G), we 
inductively define a sequence ngni . . . of nodes rii G N and a sequence -4o-4i ... of 
sets of actions % f Ai ^ A such that for alH G N the following conditions hold: 

(i) Sj Ui, 

(ii) no G /, 

(hi) A^ = {A G A: {rii, m+i) G 6 a and {si, s*+i) [= A}, and 
(iv) (sj, Sj+i) \= t' ^ t for all A G Ai and all {t, -<) G OA(nj, nj+i). 

Obviously, conditions (i)-(iv) ensure the conditions stated in definition 2 for any choice 
of Ai G Ai, except for the conditions related to fairness requirements. 

For the induction base, we choose some node ng G / such that sq \= no holds; the 
existence of some such node is ensured by condition (1), since sq \= Itiit holds by 
assumption. 

For the induction step, we assume that uq . . .rii and Aq . • . Ai-i have already been 
defined such that conditions (i) and (ii) hold for all J < i and conditions (iii) and (iv) 
hold for all j < i. In particular, we have Si \= rii. Moreover, since a ^ Spec, we know 
that {si,Si+i) ^ Next, and condition (2) ensures that (si,Si+i) \= AAm' holds for 
some action A and some transition {rii, tn) G 6a- Define rii+i = m for some such 
transition, and choose Ai as given in the right-hand side of condition (iii). These choices 
imply that \= and that Ai f 0. To prove condition (iv), assume that A G Ai 
and that (t, -<) G OA{rii, Wi+i). By induction hypothesis and the choices of rii+i and 
Ai we have {si, Si+i) \= riiAAAn'^^i and {rii, ni+i) G 6a, hence condition (3) implies 
(si, Si+i) \= t' < t as required. 

It remains to pick a sequence AqAi ... of actions Ai G Ai such that the last two 
conditions from definition 2, which concern the fairness annotations in G, are satisfied. 
Choose a sequence such that every action A G A that appears in infinitely many Ai is 
chosen infinitely often. (Such a choice is possible because A is finite.) 

Now assume that C(A) = WF for some action A G A and that for all but finitely many 
i G N, (rii, m) G 6 a holds for some m G N (otherwise the condition is obviously 
satisfied). Because we already know that Si |= rii holds for all i G N, condition (4c) 
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implies that Si ^ enabled A holds for all but finitely many i G N. Moreover, since 
a \= Spec and \= Spec => WF(j 4) (by condition (4a)), it follows that (s^, Si+i) \= A 
holds for infinitely many i G N. For every such i G N, we have {ni,rii+i) G 5a'- 
otherwise, we would obtain \= -'Ui+i from condition (4d) and have a contradiction. 
But then, condition (iii) above implies that A G Ai holds for infinitely many i G N, 
hence Ai = A holds for infinitely many i G N, which completes the proof. 

For actions A G A such that C(^) = SF, the proof is analogous, replacing “all but 
finitely many” by “infinitely many” and using (4b) instead of (4a). □ 



3.2 Model Checking Predicate Diagrams 

Since predicate diagrams are finite transition systems, it is straightforward to encode 
their runs in the input language of standard LTL model checkers such as Spin [12] 
or STeP [21]. We briefly sketch our encoding of predicate diagrams in Promela, the 
modelling language of Spin. Two variables are used to indicate the current node and 
the last action taken. The predicates in V are represented by boolean variables, which 
are updated according to the label of the current node (nondeterministically if that label 
contains neither P nor ~'P). We also add variables for every term t and relation 

-< G O such that ( f , ^ ) appears in some ordering annotation oa ■ These variables are set 
to 2 if the last transition taken is labelled by (f, ^), to 1 if it is labelled by and to 

0 otherwise. 

The fairness conditions can be stated as temporal logic assumptions when properties are 
verified of the Promela model. In order to do so, we assume that action A is enabled whe- 
never the currently active node has an outgoing edge in <5^, as asserted by condition (4c) 
of theorem 3. To capture the effect of the ordering annotations, we add the assumptions 

= 2 ) ^ □<>(&(*, ^) = 0 ) 

for every variable These assumptions ensure that transitions known to strictly 

decrease t with respect to ^ cannot be taken infinitely often unless infinitely often some 
transitions are taken that may increase the value of t. 

It is easy to see that whenever Spec < G holds, then any property verified for the 
Promela encoding of G also holds of Spec. We can therefore use model checking to 
exhaustively consider the traces of G in order to establish temporal logic properties of 
Spec. In combination with the non-temporal proof obligations stated in theorem 3 to 
establish the correctness of the abstraction, we thus achieve the desired separation of 
concerns for the entire verification of Spec. Obviously, the size of diagrams for which 
model checking is feasible is mostly limited by the number of fairness conditions and 
ordering annotations that appear in the diagram. 



3.3 Two Examples 

We illustrate the use of predicate diagrams at the hand of two examples: a two-process 
version of Lamport’s Bakery algorithm and the “dining mathematicians” mutual-ex- 
clusion protocol. We present the specifications as they are input to the generator of 
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predicate diagrams described in section 4, using the syntax of the specification langu- 
age TLA+ [19,20]. Specifications can consist of several modules that contain variable 
declarations and operator definitions. Formula Spec in the top-level module is the main 
specification. 



The Bakery Algorithm. We consider a two-process version of Lamport’s well-known 
protocol [16], shown in figure 1. Mutual exclusion between two processes is ensured 
via “ticket” variables yi and p 2 that processes draw when they wish to enter the cri- 
tical section. The variables pci and pc 2 represent the control states of the processes 
(unchanged X abbreviates x' = x). 

I MODULE Bakery 1 

VARIABLES J/l , ?/2, pCl, pC2 

Init =j/i = 0Ay2 = 0A pc\ = “11” A pc 2 = “ml” 

LI = pc\ = “II” A pc'i = “12” A UNCHANGED ( ?/l , J /2 , pC 2 ) 

L2 = pci = “12” A pc'i = “13” A ?;] = j/2 -f 1 A unchanged ( y2 , pc2 ) 

L3 = A pc\ = “13” A (?/2 = 0 V < 1 / 2 ) ) 

A pc'i = “14” A UNCHANGED ( J /1 , J/2 , pC2 ) 

i4 = pCl = “14” A pc'i = “15” A UNCHANGED ( J /1 , J/2 , pC2 ) 

L5 = pci = “15” A pc[ = “II” A y[ = 0 A unchanged ( j /2 , pc 2 ) 

Ml = pc 2 — “ml” A pc '2 = “m2” A unchanged ( j/i , j /2 , pci ) 

M2 = pc 2 = “m2” A pc '2 = “m3” A j /2 = j/i -I- 1 A unchanged ( j/i , pci ) 

M3 = A pc 2 = “m3” A (j/i = 0 V -'(j/i < j/ 2 ) ) 

A pc '2 — “m4” A unchanged ( j/i , j /2 , pci ) 

M4 = pc 2 — “m4” A pc '2 = “m5” A unchanged ( j/i , j /2 , pci ) 

M5 = pc 2 = “m5” A pc '2 = “ml” A j /2 = 0 A unchanged ( j/i , pa ) 

Next = V ii V L 2 V is V L 4 V is 

V Ml V M 2 y Ms y Mi V Ms 

Spec = A □ Next 



Fig. 1. System specification of the Bakery algorithm. 

Consider the predicate diagram G shown in figure 2. We cannot show Spec < G for the 
Bakery specification of figure 1 using theorem 3 because the attempt to prove obligation 
(2) would require proving 

A -'{pci = “l4”Apc2 = “m4”) 

A pc 2 = “m3”A(j/i = OVj/2 < J/i) 

A pc '2 = “m4” A UNCHANGED (j/i, J/ 2 ,PCi) 

^ ^(pci = “I4”APC2 = “m4”) 
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In section 4 we explain how we can construct semi-automatically a predicate diagram 
for the Bakery specification from which one can prove mutual exclusion as well as the 
desired liveness properties of the Bakery algorithm. 



The “Dining Mathematicians” Example. This is another two-process mutual exclu- 
sion protocol introduced in [6]. Processes alternate between “thinking” and “eating” 
states; they may eat only if n is even or odd, respectively. The temporal logic specifica- 
tion of the protocol appears in figure 3. 

I MODULE DM 1 

EXTENDS Natural 
VARIABLES 11, Co, Cl 



Init = n £ Nat A n > 0 A Co = “t” A ci = “t” 

Eato = Co = “t” A even(«) A Cq = “e” A n' = n A c[ = ci 
Thinko = cq = “e” A Cq = “t” A n' = n div 2 A cj = ci 
Eati = Cl = “t” A -ieven(«) A c[ = “e” A n' = n A Cq = co 
Thinki = c\ = “e” A cj = “t” A n = 3-n-|-l A Cq = cg 
Next = Eatg V Thinko V Eati V Thinki 
var = {n, co, ci) 

Spec = Init A □ Next 



Fig. 3. System specification of the dining mathematicians protocol. 

Let Dining Graph he the predicate diagram shown in figure 4. It is an easy exercise 
to show that DM. Spec < Dining Graph hy an application of theorem 3. Using the 
encoding of predicate diagrams for Spin described in section 3.2, we can establish the 
following properties: 

(Pos) □(n £ Nat An > 0) {Excl) □“’(cq = “e”Aci = “e”) 

{Liven) nO(co = “e”) {Livei) □0(ci = “e”) 

The invariants assert that n remains a positive natural number throughout any run of 
specification DM , and that mutual exclusion is ensured. The other properties are liven- 
ess properties and show starvation-freedom for both processes. In particular, property 
{Livei) can be established despite the cycle between the two leftmost states in the dia- 
gram, because the ordering annotations forbid that cycle to be followed indefinitely. 
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Fig. 4. A predicate diagram for the dining mathematicians. 



4 Using Abstract Interpretation to Construct Predicate Diagrams 

Theorem 3 can be used to justify that a given predicate diagram conforms to a given 
specification, but it may generate a number of proof obligations that is quadratic in 
the number of nodes. It is therefore desirable to construct predicate diagrams semi- 
automatically from a specification whenever this is possible. 

In [ 4 ] we have defined an “abstract animator” of temporal logic specifications that con- 
structs behaviors of system specifications where concrete values may be abstracted via 
a user-defined abstraction function. Successor states are computed by abstractly evalua- 
ting the system’s next-state relation w.r.t. the abstract values at the previous state. If the 
abstract evaluation succeeds for all reachable states, we obtain a finite approximation of 
the system’s behaviors that can be used to infer system invariants. The implementation 
of our prototype was based on the rewrite engine Logic-Solver that underlies Atelier 
B [ 29 ], an environment supporting the B method [ 1 ]. We have since extended the fun- 
ctionality of our tool in order to produce predicate diagrams that conform to the given 
system specification. 

Traditionally, the relationship between concrete and abstract states that underlies abstract 
interpretation is described by a Galois connection. We recall that a Galois connection 
between two partially ordered sets and (^2, E2) is given by two mappings 

(Li, El) (L2, E2) 

such that xi Ei 7(2:2) holds iff a(2;i) E2 2:2, for all xi € Li and X2 & L^. In our setting, 
elements of Li are sets of states and L2 is the Boolean algebra B{V) whose atoms are 
the predicates in V. The abstraction function a returns the set of predicates true or false 
of a set of states, and the concretization function 7 produces the set of states that are 
models of a set of (negated) predicates. 

Given an abstract state n G B{V), the main problem is to compute an abstract represen- 
tation of the set of successor states of the states in 7(n) with respect to some action A 
(including the next-state relation Next) of the given specification. 
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Definition 4. For m,n € B{'P) and an action A G A, we say that n is an abstract 
successor ofm ijffor all states s, t, if s G "/{tn) and (s, t) ^ A, then t G "/{n). 

Because we may alternately interpret abstract states as elements of B{V) and as predi- 
cates over concrete states, the above definition can be restated as requiring 



Since nodes of predicate diagrams are sets of V, interpreted conjunctively, we may 
assume m to be a conjunction of literals, and try to compute some successor n in 
disjunctive normal form. 

As the first step of the abstract evaluation of A from m, we try to evaluate those subfor- 
mulas of A that contain only unprimed variables to either true or false in order to simplify 
the action formula. This amounts to abstractly evaluating the guards of the action. In the 
second step, we try to evaluate as many formulas P' , for P G V, as possible in order to 
assemble information about the predicates that are true or false after the action has been 
executed. Throughout, we maintain A and the results of simplification in disjunctive 
normal form. 

Let us first describe the abstract evaluation procedure for monadic predicates. If V 
contains k monadic predicates Pi{x), . . . , Pk{x) that contain the same (concrete) state 
variable x, we let the abstract states contain k state variables xi, . . . ,Xk such that Xi 
takes values P^ or not-Pi. For example, the predicate yi = 0 might be represented by 
the variable G {zero, not-zero}. Now, every unprimed occurrence of variable x in 
A replaced by the value assigned to xi by the abstract source state m, for every xi that 
appears in m. User-supplied rewrite rules of the form are used to simplify the resulting 
expressions. The evaluation is successful if the resulting formula is of the form 



for some expressions Cpq that contain the “abstract values” Pi and not-Pi. The set of 
abstract successor states is extracted from res by picking those subformulas for which 
epq is either Pi or not-Pi. 

Example 5. In the context of the B akery specification considered in section 3.3, consider 
the evaluation of the next-state action Next from the state 



(Note that our tool allows concrete state variables to be left unabstracted; this is useful 
when variables take values from a finite domain.) 

The underlying set of rewrite rules include 



^ uiAA => n' . 




p 9 



m = {pci = “Il”,pc 2 = “m2” ,yi = zero,y 2 = zero} 



zero-\-l -A not-zero 
not-zero-f-1 -A not-zero 



zero = zero -A true 
zero = not-zero -A false 



zero < zero -A true 
zero < not-zero -A true 
not-zero < zero -A false 
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Note that expressions such as not-zero = not-zero or not-zero < not-zero cannot be 
simplified. 

Application of the abstract evaluation procedure outlined above produces the two suc- 
cessor states 

{pci = “I 2 ”,pc 2 = “m2”,^ = zero,y^ = zero} 

{pci = “Il”,pc 2 = “m3”,^ = zero,y 2 = not-zero} 

that correspond to either process taking a step in the protocol. □ 

Given a specification Spec = Init/\UNextAL, we construct a predicate diagram G as 
follows: first Init is rewritten to disjunctive normal form, producing a set I of abstract 
initial states. Starting from I , we repeatedly apply abstract evaluation for Next and for 
any action such that WF(A) or SF(A) appears as a conjunct in L in order to arrive at 
the set N of abstract states and the relations <5,4 for the chosen actions. Assuming that 
all rewrite rules are correct, the resulting predicate diagram is guaranteed to satisfy the 
conditions of theorem 3. 

The procedure described above can be extended to sets V that contain other than just 
monadic predicates, but it becomes somewhat more tedious to describe and implement 
because it can no longer simply be based on syntactic substitution. We prefer to rely on 
the strengthening technique described in section 5.2. 

5 Improving Abstract Evaluation 

If the abstraction is not fine enough, it is not always possible to successfully evaluate 
an action A with respect to a source state m, because some of the guards cannot be 
reduced to true or false. In such a situation, we can try to compute an approximation, 
introducing maybe edges. Any property proved from the resulting over- approximation 
is still valid of the original specification Spec. On the other hand, we may be able to 
eliminate maybe edges introducing an “on-the-fly” refinement of the abstraction with 
the help of an automatic proven Alternatively, we may introduce non-determinism as 
allowed in condition (2) of theorem 3 by relying on a lattice of abstractions. 

5.1 Maybe Edges 

Suppose we choose {zero, not-zero} as the abstract domain for the variables and 
i /2 of the Bakery algorithm. Then the abstract animation based on the evaluation rules 
of section 4 will fail because the expressions not-zero < not-zero that appear in the 
guards of actions L3 and M 3 cannot be evaluated. Our first approximation is to assign 
the value maybe to such uninterpreted expressions: 

not-zero < not-zero — >■ maybe 

“Maybe” values are propagated using rewrite rules such as 

maybe Amaybe -A maybe 
false Amaybe -A false 
->maybe -A maybe 
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state 


pci 


pc2 


yi 


y2 


state 


pci 


pc2 


yi 


y2 
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15 m5 


“15" 
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not-zero 
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Fig. 5. Predicate diagram with maybe edges. 

Successor states can be extracted as described above even in the presence of maybe 
conjuncts, but we remember such situations and indicate edges obtained in this way 
using dashed edges. For the Bakery specification, we obtain the graph shown in figure 5 
(the values assigned to the abstract variables are shown in a separate table). The diagram 
gives a clear indication of the progress of the two processes with the first process moving 
in the vertical and the second in the horizontal direction. 

The predicate diagram corresponds to an over-approximation of the Bakery specification 
and abstractly represents every behavior of the Bakery algorithm. It cannot be used to 
prove the invariant 



Bakery. Spec □-i(pci = “14” A pc 2 = “m4”) 

that asserts mutual exclusion for the two processes. However, every path leading to 
the abstract state 14m4 contains a dashed edge, and these edges indicate opportunities 



392 



D. Cansell, D. Mery, and S. Merz 




yi < V2 



-^{vi < V2) 



Fig. 6. Splitting state 13m3. 



for refining the approximation by reconsidering the transitions in view of the concrete 
specification. We now describe a technique that can perform such a refinement during 
the computation of the diagram. 

5.2 “On-the-fly” Refinement of Diagrams 

Maybe edges are introduced when predicates that appear in the concrete-level next-state 
relation (such as yl < y2 in the Bakery example) cannot be interpreted in the abstract 
states. We suggest to reconsider the offending transitions based on the predecessors of 
the abstract source state. More precisely, suppose that we cannot interpret a sub-formula 
Q in an abstract state m during the evaluation of action A. We may then try to evaluate 
Q' with respect to the formula nAAAm', for every predecessor n of m. In other words, 
we try to prove either of 

nAAAm' Q' or nAAAm' -•Q' 

By construction, it is never the case that both formulas are provable, and so we consider 
the three following cases: 





(1) 


(2) 


(3) 


nAAAm' => Q' 


Proved 


Unproved 


Unproved 


nAAAm' ~^Q' 


Unproved 


Proved 


Unproved 



In the first and second case, we may add Q resp. -■Q to the label of m (if m has more 
than one predecessor, the node is split into two copies). If all subformulas that originally 
evaluated to maybe can be decided one way or another, the maybe edge can be replaced 
by a standard transition. 

In the case of the Bakery example we can prove 

13m2AiVe2;tAl3m3' ^ ~^{y\ < y' 2 ) 

12m3AiVe2;tAl3m3' ^ y'l < y '2 

Consequently, state 13m3 is split into two states 13m3A?/i < j /2 and 13m3A-i(?/i < j/ 2 ) 
as indicated in figure 6. Continuing the abstract evaluation, both maybe edges leading 
to node 14m4 disappear, and mutual exclusion can be proven. 

In our implementation, we remember the subformulas of the concrete-level action that 
evaluated to maybe. If such expressions remain after rewriting completes, the tool calls 
the automatic prover Simplify [8] in order to try and solve the resulting proof obligations. 
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and splits the node as necessary. Applying this modified generation procedure to the 
Bakery specification, we arrive at the predicate diagram schematically shown in figure 7. 
In this diagram, the node at which both pci = “13” and pc 2 = “m3” are true has been 
split into two nodes that differ in the value assigned to the predicate y\ < U 2 , and the 
node 14m4 has been eliminated. In particular, mutual exclusion can now be established, 
although the diagram still contains two maybe edges. 

Because of these edges, we can still not prove liveness properties about the Bakery al- 
gorithm. However, the edges can be eliminated by forward propagation of the inferred 
properties in a similar manner. In this way we obtain the predicate diagram shown in 
figure 8 for the Bakery example which precisely represents the behaviors of the speci- 
fication modulo the chosen abstraction. Similar graphs have been produced manually, 
for example, in [14], but to our knowledge our tool is the first that is able to obtain this 
diagram semi-automatically, with the user only indicating that zero and non-zero values 
for the “ticket” variables should be distinguished. 

Running Spin on the Promela encoding of the diagram of figure 8, we can prove liveness 
properties such as Bakery .Spec {pc\ = “12” pci = “14”) as well as precedence 

properties such as one-bounded overtaking for either process. 



5.3 Using a Lattice of Abstractions 

Sometimes when we cannot evaluate an expression in the abstract world we can change 
the abstract world using a lattice abstraction. For example, with the classical calculation 
rules [10] on {odd, even} we cannot evaluate even div 2 and we cannot prove that n 
is always greater than 0 for the “dining mathematicians” specification. Instead, we can 
use an abstraction using the three abstract values zero, even^^ and odd; this amounts to 
abstracting on both predicates even(n) and n = 0. However, the expression even^^ div 
2 is yet uninterpreted. Vi^e can replace this abstract expression by another abstract value 




Fig. 7. Predicate diagram for Bakery with some maybe edges removed. 
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Fig. 8. Final predicate diagram for Bakery. 



not-zero which represents every natural greater than 0. After this evaluation we transform 
X = not-zero m X = even^^Mx = otirf. Formally, this transformation can he explained 
as a change of the degree of abstraction, cf. hgure 9. When successful evaluation of 
the predicates at the more abstract level has established that even^^ div 2 is a positive 
natural number, we can re-descend to the first abstraction based on zero, even^^ and 
odd using the following calculation rules (where the variable x that appears in the last 
rule can be instantiated arbitrarily). 



even^^-\-even^^ 




even^^ 


even^^-\-odd 




odd 


odd-\- even^^ 


-)■ 


odd 


odd+odd 




even^^ 


even^^ ■ even^^ 


-)■ 


even^'^ 


even^^ ■ odd 




even^^ 


odd- even^^ 


-)■ 


even^^ 


odd -odd 




odd 


even^'^ div 2 


-)■ 


not-zero 


even ( even 


-)> 


TRUE 


even (odd) 


-)■ 


FALSE 


X = not-zero 


-)> 


X = even 



In this way, we can automatically construct the predicate diagram Dining Graph of 
hgure 4, except for the ordering annotation that must still be justihed interactively. In 
principle, similar methods of abstract evaluation could be used to compute ordering 
annotations, but we believe that they should be used only judiciously as they greatly 
affect the effectiveness of model checking. 



6 Related Work 

The hrst work using graphs to visualize and structure temporal proofs for concurrent 
programs is due to Lamport and Owicki [27]. There, proof lattices are used to better 
explain logic rules and to “see” and so verify what a program is supposed to do. Building 
on these ideas, proof charts were introduced in Radhia Cousot’s thesis [5]. A proof chart 
for a transition system is a hnite graph with a unique start and hnal state. Proof obligations 
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Fig. 9. A lattice of abstractions. 



are associated with every sub-chart, and “return” edges can be labelled by well-founded 
orderings to guarantee termination of the system. In contrast to our diagrams, these 
approaches concentrate on illustrating the structure of the proof rather than of the system 
under analysis. 

Predicate-action diagrams proposed by Lamport [18] represent the safety part of specifi- 
cations. An interesting point is that different, complementary views about a specification 
can be illustrated by different diagrams (even for the same set of predicates), and that 
the proof of refinement relations via diagrams is considered. Manna et al [7,22,23] have 
also advocated the diagrammatic verification of temporal logic properties. The main 
difference is in the representation of fairness conditions, which we assert on the level of 
entire diagrams rather than for individual edges. This simplifies the verification conditi- 
ons related to fairness assumptions, and allows to take them into account during abstract 
evaluation. We also allow an arbitrary number of ordering annotations, which reduces 
the number of proof obligations, and should be more intuitive for a system designer. We 
have prototypically implemented refinement rules discussed in [22] that allow to split 
nodes or remove edges in our tool. Probably closest in spirit, although different in detail, 
to our work is the work by Bensalem, Saidi et al on the generation of invariants that is 
incorporated in the In Vest and SAL tools [3,2,28]. While our approach focuses more on 
abstract evaluation, they use the theorem prover PVS as their primary workhorse. Ano- 
ther conceptual difference is our emphasis on liveness properties; indeed, we believe 
that it is here that abstraction-based techniques can be used to full advantage because 
the deductive verification of liveness properties is inherently tedious and difficult. 



7 Conclusion and Future Work 

In this paper we have proposed predicate diagrams as a general framework for presenting 
Boolean abstractions of reactive systems and as a adequate theoretical basis for the 
integration of deductive and algorithmic verification techniques. We have shown that 
both safety and liveness properties can be verified from predicate diagrams thanks to the 
presence of fairness assumptions and of annotations related to well-founded orderings 
that can be associated with state transitions. While the focus of this paper has been a 
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bottom-up approach to verification of given specifications, which could he characterized 
as abstract model checking, we have found predicate diagrams to be equally useful for 
proving refinement relations between systems in a top-down development method. 

For the acceptance of formal methods in practice it is essential to achieve as much 
automation as possible, and to be able to supply relevant feedback to the developer. 
While obviously the process of computing abstractions for infinite-state systems can 
never be fully automatic, we have shown that a substantial degree of automation is 
possible. We also believe that predicate diagrams provide an adequate level of abstraction 
for system engineers, and that the abstract counter-examples that are produced when 
model checking a predicate diagram indicate how to refine the chosen abstraction. The 
generation of maybe edges should also help clarify missing predicates or evaluation rules 
for the computation of predicate diagrams. 

Some small-scale case studies have convinced us that the method is powerful and really 
helps in verifying reactive systems. Our current prototype implementation is based on the 
rewriting engine Logic Solver from Atelier B [29], the automatic prover Simplify [8], 
and the model checker Spin [12]. Besides carrying out further case studies, we intend to 
concentrate on the representation of hierarchy and refinement in the formal development 
of reactive systems via predicate diagrams. 
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Abstract. The verification of dynamic properties of a reactive systems 
by model-checking leads to a potential combinatorial explosion of the 
state space that has to be checked. In order to deal with this problem, 
we define a strategy based on local verifications rather than on a glo- 
bal verihcation. The idea is to split the system into subsystems called 
modules, and to verify the properties on each module in separation. We 
prove for a class of PLTL properties that if a property is satisfied on 
each module, then it is globally satisfied. We call such properties mo- 
dular properties. We propose a modular decomposition based on the B 
refinement process. 

We present in this paper an usual class of dynamic properties in the 
shape of n(p Q), where p is a proposition and Q is a simple temporal 
formula, such as Qq, <0>g, or qUr (with q and r being propositions). 
We prove that these dynamic properties are modular. For these specihc 
patterns, we have exhibited some syntactic conditions of modularity on 
their corresponding Biichi automata. These conditions define a larger 
class which contains other patterns such as D(p Q>{qUr)). 

Finally, we show through the example of an industrial Robot that this 
method is valid in a practical way. 

Keywords. Refinement, modularity, Verification, model-checking, Biichi 
automata. Propositional linear temporal logic PLTL, B specification. 



1 Introduction 

This paper is about the problem of the verification of finite reactive systems 
[18,3,4]. The work that we present takes the B events system specification as a 
context [1], in which we introduce and verify dynamic properties of liveness and 
safety [16,17]. 

A solution for the verification of dynamic properties is to use a model- checker 
[10,11]. In comparison with proof techniques, such an approach offers the advan- 
tage of a possible and entire automatization, without the use of variants and 
loop invariant. The well known inconveniences of it are its limitation to finite 
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state systems and the potential combinatorial explosion of the number of states 
to be checked. 

The problem of combinatorial explosion has been treated through various 
methods with time or memory space gain as a result. Let us cite by the way the 
memory compression techniques [12], the partial verification techniques based on 
heuristics [9], the memory efficient algorithms [6], the partial order techniques 
[21,8] suppressing useless interleaving, the techniques of symbolic representation 
of the states with BDD and the techniques of state vector abstraction [7]. 

The approach that we expand below, based on the verification by model- 
checking, attacks the problem of the combinatorial explosion in a different way. 
We use a decomposition of the reachability graph into several modules. We then 
verify the properties module after module. We prove that an interesting class 
of PLTL properties can be verified modularly. In others words, if the property 
holds on every module, we prove that it holds on the whole system. 

All the decompositions are not equivalent. For some decompositions and for 
dynamic properties that can be verified in a modular way, the modular verifi- 
cation is valid whereas for some other decompositions, the modular verification 
might fail even when a property is true. Thus, the problem consists in finding a 
“good” decomposition. We use the notion of refinement induced by the B me- 
thod to produce the modular split. The refinement of an abstract model by a 
concrete one induces a split of the concrete graph into subgraphs, according to 
the structure of the abstract graph. On such subgraphs, a modular verification 
is valid. 

As a matter of fact, the B refinement process introduces new dynamic pro- 
perties at each level of the refinement, together with the new events to which 
they are linked. So, the decomposition by refinement “keeps” the sequences of 
new events within subgraphs. This is the reason why such a split, which relies 
on a partition of the state space, is a “good” modular split. In other words, the 
refinement process produces a semantic split. 

Some other modular approaches have been proposed that use compositional 
verification [13]. They are based on the parallel operationality which allows to 
split the model into components that contribute to the entire state space in a 
multiplicative way. Our approach splits the model of a component in an addi- 
tive way. Since on one hand the B refinement allows the expression of parallel 
composition and, on the other hand, it preserves all the PLTL properties but 
the ones that contain the next operator, the two techniques are compatible. It 
is possible to verify separately a process component with a modular approach in 
the sense of our proposition. 

Conversely, in [15], Karen Faster and Orna Grumberg present a modular ap- 
proach in our sense to temporal logic model-checking of software, in which a pro- 
gram text is partitioned into sequentially composed subprograms. The model- 
checking is then performed on each subprogram, separately but not indepen- 
dently. As a matter of fact, some information (by means of an assumption fun- 
ction) needs to be transmitted from one module to another. This is due to the 
fact that the partition proposed is a syntactic one. 
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Based on the refinement, the modularity that we propose is a semantic one. 
Furthermore, our modular approach is compatible with the use of the techniques 
that reduce the combinatorial explosion mentioned above. 

Section 2 describes the concept of modular verification. In section 3, we define 
a class of dynamic properties by means of Biichi automata, and we prove that 
the properties in this class can be verified in a modular way. Section 4 defines 
the refinement relation between the abstract and refined specifications in B. To 
illustrate this work, we give in section 5 a simple example of an industrial Robot 
in order to exhibit the abstract and detailed specifications with their PLTL 
properties. Finally, we conclude this work and give some future directions of 
research. 



2 Modular Verification 

2.1 Principle of the Modular Verification 

The basic idea of the modular verification is simple. Since a transition system 
might be too large to be verified by model-checking in an exhaustive way, we 
shall split it into several smaller pieces called modules in order to perform the 
verification on each module in separation. 

Notice that every state and transition of the original transition system must 
belong to one module at least, so that the modular split must consist of a par- 
tition for the transitions and of an overlapping for the states, that are possibly 
both the target of a last transition of a module and the source of a first transition 
of another module. 

Thanks to the modular split, a property can then be verified by model- 
checking on each module in separation, so that it is never necessary to keep the 
whole transition system in memory. With such a verification, we want to be able 
to tell whether the property is globally true or not. 

2.2 Modular Property 

When a property is true on every module, it is not always possible to conclude 
that it is globally true. Further in this section, we look at the PLTL property 
pattern n(p => □ 5 ) which is possibly true on every module although globally 
false. Thus, we have to distinguish the properties that can be verified in a mo- 
dular way and the ones that can not. We will say that a PLTL property P is 
modular if and only if 

P true on every module => P globally true. 

We will give a formal definition of a modular property in definition 4. 

Thus, given a specification with dynamic properties in PLTL, we first have to 
make sure that these properties are modular before we verify them in a modular 
way. Section 3.3 shows that the three PLTL property patterns D(p => Qjq), 
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□ (p <0g) and n(p qtir), where p, q and r are propositional formulae over 

the states of a transition system, are modular. 

Notice that 



P true on every module P globally true 

is equivalent to 

P globally false P false on one module at least. 

Thus, in order to detect the modularity of a property, we will suppose that this 
property is globally false. If we can prove that in this case it also false on a 
module, then we know that the property is modular. 

As examples, let us look at the two property patterns n(p => Og) and n(p => 
□g). The first pattern is modular, as will be proved in section 3.3. The second 
pattern is not modular. In both cases, we suppose that the properties are globally 
false. That is, we consider sequences that satisfy the negations of the properties. 
The modular split will possibly “cut” the sequences, and so we look whether the 
cut sequences still negate the properties or not. 

A Modular Property: n(p Oq)- Let us suppose that the property P = 
□ (p <C>g) is globally false. Then, the negation of the property is true. Notice 

that is equivalent to <C>(p A □“■g). This means that there is a sub-sequence 
satisfying p A □-■g. Fig. 1 shows such a sequence, and how it is cut by a two 
modules split. 



-iD(p =:> <^g) <^(p A □“■g) 




Fig. 1. Modular property D(p => <J>g) 

In module M 2 , there is no state satisfying p and so P is trivially true in 
this module. In module Mi, a state satisfies p which is followed by states all 
satisfying -ig. As a consequence, P is indeed false in this module. 

This is due to the fact that, with property pattern n(p => <C>g), once a state 
satisfying p has occurred, a response (in the shape of a state satisfying g) is 
waited for. If this response never comes (D-ip), one may cut the sequence, it still 
will not come. 
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A Non-modulta' Property: D(p => nq). Let us suppose that the property 
P = □(p => □(/) is Klohally false. 'I'hen, the negation of the properly is true. 
Notice that is equivalent to A 0 '<?)• This means that there is a sub- 
sequence satisfying pA^^q. Fig. 2 shows such a sequence, and how it is cut by 
a two modules split. 



-'U(p -> Ll(/) <->■ <^(p A <>-'17) 




Fig. 2 . Noii-modulor properly Dg) 

Tn module M 2 , there is no state .sati.sfying p and so P is trivially true in 
this module. In module M\, the state satisfying p is now followed by states all 
salislyhig q, so that lliis cut sequence no longer negates P. As a consequence, P 
is possibly true in that module as well, although it is globally false. 

This is due to the fact that, once a state satisfymg p has occurred, the 
sequence remains possibly true as long as a slate satisfying ->q has not occurred. 
If the sequence is cut before that .state, then it pos.sibly satisfies P. 



3 Verification of the Modularity 

Before we perform a modular verification, we have to prove that the dynamic 
properties that we want to verify are modular. 

In this section, we are looking at a class of dynamic properties defined from 
the Biichi automata [20] that recognize their negation. We call this class BAq. 
We prove that every property in the class BA 2 is a modular property. 

As examples of properties that belong to the class BA 2 , we prove that, amon- 
gst others, the dynamic properties suggested by the tliree patterns of dynamic 
constraints introduced by J.-R. Abrial in [2] are modular. They consist in the 
three following patterns of PI/TL properties: U(p — > Qq), 1-J(p O'?) 

□(p pl^q) where p and q are propositional formulae over the states of a tran- 
sition system. 

Let P be a PI/TL property. We have ever noticed that we prove P modular 
equivalently by proving that if P is false on the whole transition system, then it 
is false on one module at least. For tliis we consider the Buchi automaton that 
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recognizes the negation of P. We know that every path a in the whole graph that 
negates the property is recognized by this automaton. We then prove that there 
is a part of such a path cr that belongs to one module and that is recognized by 
the Biichi automaton. This proves that the property is false on that module. 

3.1 Definitions for the Verification of the Modularity of Dynamic 
Properties 

In this section, we introduce the notations and the definitions that we use to 
establish that the three above patterns are modular. 

Definition 1 (Transition System) A transition system is a 6-tuple TS = 
< A, S, S'o, — >■, AP, L > where A is an alphabet labelling the transitions, S is the 
set of states, Sq Q S is the set of initial states, — ^ is the transition relation 
(— >-C SxAxS), AP is a set of propositions and L : S' 2^^ is the assignment 
function. 

Let TS =< A,S,Sq,^,AP,L > be a transition system. Let us consider a 
partition of the set S of states. Each part of the partition can be regarded as 

an equivalence class EQi such that S = \^EQi. Some states in EQi are the 

source states of some transitions in — whose target states are not in EQi. We 
call these transitions the exiting transitions of EQi. A module M of a transition 
system TS is a, transition system whose set of states is composed of the states 
in EQi augmented with the target states of the exiting transitions. 

Definition 2 (Module) Let TS =< A, S, Sq,^, AP, L > be a transition sy- 
stem. Let Vs be a partition of S. Each equivalence class EQ of Vs allows the de- 
finition of a module which is a transition system TS' =< A, S' , S'q, — AP, L' > 
defined in the following way: 

— S' = EQ U {s G 5/3si A s G— >■ Asi G Si A s ^ A} 

S' is the set of states of the class augmented with the exiting states, 

— -a'= {si A s G— >■ /si G S' A s G iS"} 

— is the set of transitions that link the states of S' , 

— S'o = {s' G S' /3s A s' G^ As A s' 

S'q is the set of states of S' reachable from a transition in — >■ that is not in 

— L' is the restriction of L on S'. 

We call internal states the states of the modules that are in EQ, whereas 
we call exiting states the target states of the exiting transitions. With such a 
definition, we have indeed a partition of the transitions ofTS and an overlapping 
of the states of TS. 

Notations 3 Let P be a dynamic property in PLTL and TS a transition sy- 
stem. We denote TS \- P the fact that the property P is satisfied on TS. Lts 
meaning is defined by the semantics of PLTL. We denote s \= p the fact that a 
state s satisfies a boolean proposition p. Thus, we have s \= p iff p G L(s). 
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Given a PLTL property P, a transition system TS and its split into a set 
Ad of modules M, we want to prove that P is modular. 

Definition 4 (Modular Property) Let P be a PLTL property. Let j\4 be the 
split of a transition system TS into modules. The property P is modular iff 

(VM € Ad, M h P) ^ h P 



whieh is equivalent to 

TS P P ^ 3M G Ad A cr path of M s.t. a \ — P . 

Definition 5 (Path of a Transition System) A path a = sqSi . . . Si . . . of a 

transition system TS =< A, S, Sq, — >■, AP, L > is defined as a sequence (finite or 
infinite ) of states linked by a transition. 



'^Si G fJ, G (J, 3t G ^ s.t. t — Si — ^ . 

Definition 6 (Biichi Automaton) A Biiehi automaton is a 5-tuple B = 
< bQ,B, AP, — Accept > where: 

— bo is the initial state, 

— B is the finite set of states (bo € B), 

— AP is a set of boolean propositions (the labels of the transitions), 

— — is the finite set of transitions labeled by propositions of Pb •' ~^bQ B x 
AP X B, 

— Accept Q B is the set of accepting states of the automaton. 

Remark. A Biichi automaton is defined as a transition system in which we 
distinguish accepting states, and whose transitions are labeled with boolean 
propositions. As the states of a Biichi automaton are not valued, we need not 
introduce the assignment function L in its definition. 

Definition 7 (Recognition of a Finite Path) A finite path a = sqSi . . . s„ 
of a transition system TS =< A, S, Sq, — >•, AP, L > is recognized by a path r = 
bobi . . . of a Biichi automaton B =< bo, B, AP, — >-b, Accept > if and only if 

i) yi,0 < i < n. Si € a ^ 3pi G AP s.t. bi ^ G Tsand Si ^ pi 
ii) bn+i G Accept 

Definition 8 (Recognition of an Infinite Path) An infinite path a = 
sqSi ... of a transition system is recognized by a path r = bobi ... of a Biichi 
automaton if and only if 



i) \/i > 0, Si G a 3pi G AP s.t. bi A- G Tsand Si ^ pi 
ii) accepting states appear infinitely often in r. 



Modular Verification for a Class of PLTL Properties 



405 



3.2 Intuitive Presentation of the Demonstration of the Modularity 
Verification Correctness 

Given a PLTL property P and a transition system TS split into a set At of 
modules M, we want to prove that: 

TS V P ^ 3M € M A a path of M s.t. a I — 'P . 

For a path a of the whole transition system that negates P, we prove that a 
part of a exists that is entirely within a module and that negates P as well. In 
order to do this, we isolate in cr the suffix that is sufficient to negate P (we call 
it the minimal sujjix of the negation of P and we prove that every prefix of this 
suffix still negates P. As a consequence, cr can be “cut” anywhere by a module, 
it still negates P. 

Let us now justify the usefulness of this notion of minimal suffix of the ne- 
gation of P. Let cr be a path of the whole graph that negates P: a \ <P. The 

path cr possibly contains useless information as for the negation of P. Consider 
as an example the following property P: □(?? (fq). A path including a state 

Sk satisfying p A -•q followed by states all satisfying -•q is a path that satisfies 
->P, whatever the states preceding Sfc. So, we are only interested in the part of 
the path that starts with state s^. Thus, given P and cr, we consider a suffix 
cr^, which is the suffix of cr still satisfying ->P obtained by removing from cr the 
longest possible prefix. This suffix cr^ is called the minimal suffix of negation of 
P. 

Definition 9 (Minimal Suffix of Negation of a Property) Let P be a 

PLTL property and let cr = sqSi . . . Si . . . be a path of a transition system such 
that a I — 'P . We denote ai the suffix ... of a. 

If an integer m exists such that: Vi € [0 . . . m], cr^ I 'P and Vi > m, —'{ai h 

~'P), then the suffix a^ is called the minimal suffix of negation of P. 

Two situations have to be considered. 

1. the states involved in am all belong to a unique module M. Thus, M I — <P 

2. the states involved in am belong to distinct modules. We consider in this 
case a prefix a'^ = SmSm+i ■ ■ - Sk such that all the states involved in cr(^ 
belong to the same module. Thus, we have to prove that a'^ I — ‘P. 



3.3 Demonstration of the Modularity of the PLTL Properties 
Encoded by a Biichi Automaton in the Class BA 2 

Let us consider a class of Biichi automata that we call BA 2 , for which all states of 
the automata are accepting states, with the exception of at most the initial state 
and its direct successors, provided that there is no transition between any of such 
(non-accepting) direct successors. In other words, every path r = bobib 2 ... of 
an automaton in the class BA 2 that recognizes the minimal suffix of negation of 
a property is such that Vi > 2, 6^ G Accept. 
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Definition 10 (The Class BA^) Let B =< B, Accept > be a Bii- 

ehi automaton. B £ BA 2 iff 

Vr = bobi . . . path ofB, 3fc > 0 s.t. Vi,0 < i < k, bi = bo, 
and Vj > k, bj € Accept . 

The automata encoding the properties n(p => Qq), n(p => (fq) and n(p 
qUr) (represented in figures 3, 4 and 5) belong to the class BA 2 - We prove that 
all the PLTL properties that can be encoded by an automaton of the class BA 2 
are modular properties. 

Let P be a PLTL formula, and let cr be a path of a transition system TS 
such that a I — 'P. Let u„i be the minimal suffix of a that negates P, and let BA 
be the Biichi automaton that encodes ^P. We suppose BA £ BA 2 - Lemma 1 
proves that a prefix of am whose all the states belong to the same module always 
exists. Moreover, it proves that this prefix is at least two states long. Lemma 2 
proves that when recognizing Um, BA can not get back to its initial state once it 
has left it. In other words, we eliminate the loop on the initial state of BA (see 
figures 3, 4, 5). Theorem 3 concludes that if the above conditions are true, P 
is still negated on a module. It is obvious as BA is only composed of accepting 
states from the third one, and so the recognition will be “cut” on an accepting 
state. In other words, BA £ BA 2 is a sufficient condition for P being a modular 
property. 

Lemma 1 Let P be a PLTL formula, a a path of a transition system TS sueh 

that a I iP, and am = SmSm+i ■ ■ ■ the minimal suffix of a that negates P. 

A prefix a'.^ of am such that all the states in a'm belong to the same module 
always exists. The prefix a'm is at least 2 states long. 

Proof. Consider the prefix only composed of the first two states of am- <y'm = 
SmSm+i- Sm and Sm +1 belong to the same module. As a matter of fact, two cases 
have to be considered: 

1. Sm and Sm+i belong to the same equivalence class. Then they basically 
belong to the same module ; 

2. Sm and Sm+i belong to two distinct equivalence classes EQ and EQ' . Then 
Sm+i is the target state of an outgoing transition of EQ and thus Sm and 
Sm+i belong to the same module. 

Lemma 2 Let P be a PLTL formula, a a path of a transition system TS such 
that a h -'P, am the minimal suffix of a that negates P, and BA the Biichi 
automaton that encodes -'P. 

<7m = sqSi ■■■ is recognized by a path r = bobi ... of BA where initial state 
bo only occurs once. 

Proof. Let i > 0 be an integer such that b^ = bo. Then, cr^ = ... is a suffix 

of a recognized by = 6i6i+i .... So, ai I 'P, which is a contradiction since 

am is the minimal suffix of a that negates P. 
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Theorem 3 All the PLTL properties eneoded by a Biiehi automaton in the class 
BA2 are modular properties. 

Proof. Let P be a PLTL formula, and let TS' be a transition system which is 

split into a set AA of modules. Let cr be a path oi TS such that a I >P, and 

= sqSi ■ ■ ■ be the minimal suffix of cr that negates P. Let finally BA = 
< bo,B, AP,^ba, Accept > be a Biiehi automaton such that BA G BA2. 

A prefix a!^ = sqSi . . . Sfc of am exists such that all the states involved in a!^ 
belong to a module M G M. Moreover, a'm is at least 2 states long (lemma 1). 
Let us prove that a'm I — ‘P. 

We have am I 'P- So, a path Tm = ■ ■ ■ of BA exists that recognizes 

am- Since BA G BA2, we have: Vi < 2, b^ G Accept (lemma 2). Let us consider 
the two following cases: 

— let a'm = sqSi. Then r'm = recognizes a'm as 62 £ Accept 

— let a'j^ = So . . . Sfc with fc > 1. Then ■ ^fe+i recognizes a'^^ as 

6fc+i G Accept. 

As a consequence, a'm I — 'P- Finally, 

TS A P ^ 3 M G M. A a'm path of M s.t. a'm I — <P ■ 

3.4 Modularity of the Three Modalities Introduced in B 

In order to prove that D(p => Qq), D(p Dq) and D(p qUr) are modular, 
we simply prove that the automatons of the negations of these patterns belong 
to BA2. 

Pattern 1: n(p O?)- Suppose this property is false on the global graph. 

Then a path a exists such that cr I iD(p => Qq) (which is equivalent to cr h 

‘O'iP A Q-'q)). The Biiehi automaton that encodes such a property is given in 




True True 



Fig. 3. Biiehi automaton encoding -iD(p Oq) 

Figure 3. It belongs to the BA2 class and thus D(p Qq) is modular. 

Pattern 2: n(p O?)- Suppose this property is false on the global graph. 

Then a path a exists such that a I in(p => ffq) (which is equivalent to cr h 

<0(p A O-iq)). The Biiehi automaton that encodes such a property is given in 
Figure 4. It belongs to BA2 class and thus D(p => ffq) is modular. 



408 



P.-A. Masson, H. Mountassir, and J. Julliand 




True 




not q 



Fig. 4. Biichi automaton encoding -'□(p => <C><?) 

Pattern 3: n(p qUr). Suppose this property is false on the global graph. 
Then a path a exists such that a h “'□(p qUr) (which is equivalent to 
a h <0(p A -'{qUr))). The Biichi automaton which encodes such a property is 



not r 




Fig. 5. Biichi automaton encoding ^ qUr) 

given in Figure 5. It belongs to the class BA 2 and therefore n(p qUr) is 
modular. 

4 Refinement and Modules 

4.1 Modularity and Modules 

Until now, we have only considered abstract partitions of the state space, without 
giving any indication on how to find a “good” partition. As a matter of fact, in 
order to prove in a modular way that a property P is true, P has to be true on 
every module. But with a random split of the transition system, it is possible 
that some modules find that P is false, whereas another split would have found 
P true on every module. 

The question is, for a given modular property, how can we find a partition 
that makes the verification module by module successful ? 

Our purpose here is to suggest a partition of the state space of a transition 
system into several components, this partition being based on a refinement re- 
lation. The refinement that we use is temporal in the sense that the system is 
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observed more often. Thus, details such as new variables and new events are in- 
troduced step by step. They are observed between the old events in the abstract 
specification. The new properties are concerned with sequences of news events 
and it is suitable to verify them only on derived subsystems. We call old what is 
concerned with the abstract specification and new what is concerned with the 
refined specification. 



o 



old event 



o 




Fig. 6. Refinement of an abstract transition 

Let us recall some notions given in a paper published at IFM’99 [14]. Intui- 
tively, the figure 6 schematizes the refinement of an abstract transition t labeled 
with an old event into a family of refined transitions in which some conditions 
hold. We briefly define these notions informally. 

— each labeled transition t is refined by a set of refined paths made of transi- 
tions labeled with the new events and terminated with a transition labeled 
by the label of t, 

— the initial state of the abstract transition is refined by the initial states and 
all the intermediate states of the paths, 

— the final state of the abstract transition is refined by the final states of all 
paths. 

The modular verification of a PLTL property P consists in 

— computing the set of modules, 

— verifying on each module by model-checking if P is satisfied or not, 

— concluding that P is satisfied if all the modules satisfy P. 

In the rest of this section we explain why the modular verification concept 
concerns the modules of the refined specification, rather than the full specifica- 
tion. The introduced dynamic properties concern the new events in the modules 
obtained at this step from the abstract specification. Each module is described 
as a transition system obtained from a state by application of the new events. 
In the modules, the new states are pointed in and pointed out by the old events 
of the abstract specification. The new transitions are labeled by the new events. 
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The verification of the dynamic properties is only performed on this state space 
augmented with its immediate neighbour states, on the border. Thus, semanti- 
cally, each old transition is refined by some chains of new events terminated by 
a transition labeled by an old event. We establish the relation between a veri- 
fication on modules and a verification on the whole system. In other words, we 
are essentially looking for conditions allowing us to perform local verifications 
rather than global ones. 

4.2 B Events and Transitions Systems 

We give some formal definitions for a B specification extended with PLTL for- 
mulae, and its semantics with a labeled transition system TS. The transition 
system semantics of a i? specification is directly obtained from the Before/ After 
predicate semantics of the B event systems given in [ 1 ], for the class of finite 
systems. 

Modules are defined as particular labeled transition systems that refine a 
state and the set of transitions whose this state is source in the abstract speci- 
fication. 

Definition 11 (Event System) An event system is a 6-tuple ES =< V,I,F, 
Init, A,Ga > which consists of 

— a set V of variables, 

— an invariant I, 

— a set F of formulae, 

— an initial action I nit to initialize variables, 

— an alphabet A of label of events, 

— a set Ga of events definitions in the shape select g then a end where g 
denotes a proposition and a is a generalized substitution as defined in the B 
method [1], 

Consider now two labeled transition systems TS\ =< Ai, ^i, — >-i, 

AP,Li > and TS2 =< A2, S2, S20, ^2, AP, L2 > semantics of ESi =< 
Fi,Initi,Ai,GAi > and ES2 =< V2, h, F2, Init2, A2, Ga^ >■ 

Definition 12 (Refinement of an Abstract Transition) A path (T2 ofTS2 

a 

refines an abstract transition t = s to s' G — ofTSi denoted (J2^t iff 

— a2 = Si ... Sn is a finite path s.t. the transitions ti = Sq ^ Si, . . . , = 

Sn-2 Sn-i are labeled with new events 

Vtj = 1 — )■ Si € — ^2 \ 'F i ^ n, a^ Ai A Uj € A2 , 

— the label of the transition tn = s„_i ^ s„ is the same than the one of t: 

(Xfi — O4, 

— the valuations of all the states, except the last one, of the path U2, do not 
contradict the valuation of the source state of t 
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“ the valuation of the final state of 02 does not contradict the valuation of the 
target state of t 

Definition 13 (Refinement of a Transition System) Let TSi and TS2 be 

two labeled transition systems. We define the set E of paths CT2 of LTS2 which 
refine each abstract transition t C — enabled from s £ S\ as follows: 

\/t = S s' G— >■!, V(72 = So . . . Sn path of TS2, tT2 c t (72 s . 

Definition 14 (Module Derived from the Refinement) Let L2 be the glu- 
ing invariant of ES2- A module of TS2, associated with a state s G S\ and 
an abstract transition t £— is a labeled transition system TS =< A, S, 

, AP, L > where 

— ^ is the set of transitions such that 

VcT2 = ti . . .tn & E,\/i s.t. 1 < i < n,ti , 

— S is the set of states such that 

S = {s' /s' € S2 and s' A l2 => s}U 

{s" /\/t = Si-i -A Si G— s" = Si_i V s" = Si} , 

— So is the set of initial states such that 

So = [s' /s' G 5 A Vt = Si_i 4 s, G T, sV sj ■ 

Informally, a module is a labeled transition system defining all paths (J2 of 
TS2 which refines each abstract transition t enabled from one state s G Si. 
Notice that the number of modules in TS2 is the number of states in TSi. 

The specification refinement guarantees essentially three points for a labeled 
transition system 

— the refinement of each transition of the abstract transition system by a set 
of refined paths, 

— the connectivity between the paths of the modules with the abstract transi- 
tions, 

— the modules are free from deadlocks and livelocks. 

All these definitions, and the consequences of the refinement of specification 
are established and proved in [5]. 

5 Specifications of the Robot Example 

In order to make these notions clear, we illustrate them with the example of an 
industrial robot composed of an Arrival Device, an Exit Device and a Carrier 
Device. This robot carries some parts by moving from the Arrival Device to 
the Exit Device. We first give an abstract specification and then we give two 
refinement levels of the system. The indices 0, 1 and 2 of the variables indicate 
the level of refinement. 
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5.1 Informal Specification 

The figure 7 represents the physical system. The Carrier Device (called CD) 
takes a part from the Arrival Device (called AD) and places it on the Exit 
Device (called ED). We first describe it as an abstract system, considering only 
two operations to load and unload a part. It simply consists in the Carrier Device 
taking a part and putting it onto the Exit Device. 

Exit Device 

[ ] 



Part 

Carrier Device 



Arrival Device 




Fig. 7. The robot 



Informal Presentation of an Extended B Specification. We describe a 
specification as an abstract system as in B\\]. It is composed of two parts. 

— a descriptive specification that indicates what the system does, 

— an operational specification that indicates how the system proceeds. 

The descriptive specification is essentially composed of a list of variables and 
of an invariant expressing safety properties restricting the set of valid states. 
In order to complete this part, we have proposed an extension of those systems 
with dynamic properties such as liveness, in the shape of PLTL formulae. In 
the example produced below, we use the four future temporal operators called 
usually Always, Next, Eventually and Until, denoted respectively by the symbols 
1^, Oi 0 and U. 

The operational specification is also composed of two parts. 

— the description of the initial states in the Initialization section, 

— the description of all the events in the shape of guarded actions. The semantic 
of such an event is that it is enabled when the guard is true, and in that case 
the action is performed, so that it transforms the state of the system. 

The verification phase makes sure that both invariant and dynamic properties 
hold with the operational specification. As in the B method, the invariant is 
proved by means of a theorem-prover, but we will use a model-checker in order 
to verify the dynamic properties on the derived transition systems. 
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Abstract Specification. In this first approach of the system, we focalize our 
observation on one component and we only look at the behaviour of the Carrier 
Device. We ignore what happens to the other devices. There are only two states: 
one when the device is free and one when it is busy. The specification proposed in 
figure 8 uses only one variable that gives the status of the Carrier Device denoted 
CDq C {free, busy}.The invariant property gives the sorting of the variables. 
Two events are introduced in order to load and unload the part. 

System Robots, 

Variables Vo={CDo} 

Invariant Io=CDq G {free, busy} 

Dynamic properties Poi=D(CDo = busy => {}CDo = free) 

Initialization InitQ=C D q ~ free 

Events Loado= Select CDq = free then CDq := busy end 

Unloado= Select CDq — busy then CDq -.= free end 
end Roboto 



Fig. 8. Abstract specification of the robot 

The dynamic property Pqi is ^ liveness property that states that when the 
Carrier Device is busy, then eventually it becomes free. 

The corresponding transition system is represented in figure 9. It has two 
states and two events. It represents all the execution paths by means of a finite 
state system [3]. In this case, there is only one variable with two possible values. 
The transitions are labeled with the events Load and Unload representing the 
evolution of the system from one state to another. 




UnLoad 



Fig. 9. The abstract transition system 



5.2 Refined Specification 

We now present a possible refined specification of the specification given above. 
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Informal Presentation of a Refinement of Specification. As in the B 

method [1], we use the concept of refinement. The idea is to enhance the detail 
level of observation of the system, so that the refined specification gives further 
details on what the system does and how it proceeds. Thus, refinement after 
refinement, the description will go from a high level specification to a specifi- 
cation that can be directly implemented. The refined specification contains the 
same sections than the abstract one: Variables, Invariant, Dynamic Properties, 
Initialization and Events. 

The figure 10 gives a refined specification of the Robot. Both abstract and 
refined specifications must respect the following constraints: 

— the two sets of variables are disjoint, 

— the new invariant, also called the gluing invariant, expresses a relation bet- 
ween the two sets of variables of the two levels, 

— the dynamic properties are new properties concerning the behaviour induced 
by the new events, 

— the old events are described again in such a way that they are refined, 

— the new events are introduced. 

In the B method, the refinement relation is verified and warrants the abstract 
invariant properties. The old dynamic properties are preserved by refinement 
notion as defined in [2]. This question is not treated in this paper in which we 
consider only the verification of new dynamic properties. 

First Refinement of the Robot. The refined specification in figure 10 settles 
the following point: the Carrier Device moves into two directions denoted Up 
and Down. The Up movement specifies that the Carrier Device is busy and goes 
up to the Exit Device in order to put a part. The Down movement specifies that 
it goes to the Arrival Device in order to take another part. We only need one 
new variable PosCDi G {Down, Up} which statues the position of the Carrier 
Device. 

The variables of the levels 0 and 1 are glued by the gluing invariant. The old 
events are refined with the new constraints and keep the same label. The guards 
of the events are reinforced. We have two new properties for this specification 
and they concern only the movement of the Carrier Device. They are safety 
properties. The properties P\^ and P\^ ensure that when the Carrier Device 
goes up it is busy, and when it goes down it is free. The transition system 
associated to this first refinement of the specification is given in figure 11. 

Second Refinement of the Robot. From this specification and with the same 
process, we give another refinement through a third detailed specification by 
introducing the component Exit Device. When a part is in it, it can be removed. 
Two news variables ED 2 and AD 2 are introduced with the possible values free 
or busy. Once again, the old events are refined and the guards are reinforced. 
Two new events are introduced, denoted ArrivalPart 2 and Evac 2 . The first 
one expresses that when a part is on the Arrival Device, the Carrier Device 
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System Roboti refines Roboto 

Variables Vi={CDi, PosCDi} 

Invariant 7i={C-Di = CDq A PosCDi G {Down, Up}} 

New Dynamic Properties Pi,^=0[PosCDi = Down A Q{PosCDi = Up) 

=> CDi = busy) 

Pi2=0(PosCDi = Up AQ){PosCDi = Down) 
=> CDi = free) 

Initialization Initi=CDi := free A PosCDi := Down 

Old Events 



Loadi= 

U nload\ = 

New Events 

StopUpi= 

StopDowni = 

End 



Select CDi = free A PosCDi — Down 
then GDi ;= busy end 
Select CDi = busy A PosCDi = Up 
then CDi ;= free end 

Select CDi = busy A PosCDi — Down 

then PosCDi := Up end 

Select C-Di = free A PosCDi = Up 

then PosCDi := Down end 

Roboti 



Fig. 10. First refinement of the robot specification 




Fig. 11. The first refinement transition system 
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transports it to the Exit Device. The second event removes the part from the 
Exit Device. The figure 12 gives the obtained specification. 



System Robot2 refines Roboti 

Variables V2HCD2, P0SCD2, AD2, ED2} 

Invariant l2={CD2 = CDi A P0SCD2 = PosCDi 

AAD2 € {free, busy} A ED2 € [free, busy}} 
New Dynamic properties P21 = 11 ( 671)2 = busy CD2 = busy 



Initialization 


U {CD2 = busy A ED2 = free)) 
Init2=CD2 := free A P0SCD2 ;= Down 


Old Events 

Load ,2 = 


Select CD2 = free A P0SCD2 = Down 


Unload2 = 


then CD2 := busy end 

Select CD2 = busy A P0SCD2 = Up 


StopUp2 = 


then CD2 := free end 

select CD2 = busy A P0SCD2 = Down 


StopDown2= 


then P0SCD2 ;= Up end 

Select CD2 = free A P0SCD2 = Up 


New Events 

PartArrival2 = 


then P0SCD2 := Down end 

Select AD2 = free then AD2 := busy end 


Evac 2 = 


Select ED2 = busy then ED2 ;= free end 


End 


Robot2 



Fig. 12 . The second refinement specification 

The gluing invariant states that the variables are identical to their abstrac- 
tion. The dynamic property P21 states that the Carrier Device remains busy 
until the Exit Device is free. The labeled transition system given in figure 13 re- 
fines the labeled transition system of figure 11. It is divided into 4 modules. The 
modules M{ and Mg both contain 6 states and 6 transitions, and the modules 
M 2 and M4 both contain 8 states and 8 transitions. 

5.3 Verification of the Properties 

We summarize the results of the modular verification of the properties Pqu 
P ij, P12 and P2j presented above. These 4 dynamic properties have the Biichi 
automata of their negations in BA 2 and so they are modular properties. It is 
sufficient that we verify them on each module in separation. They can be verified 
by a simple model-checking. 

- Po, =n(CPo = busy => (}CDq = free) is satisfied in the abstract specifica- 
tion at the level 0. 

— Pij=n(PosCPi = Down A Q{PosCDi = Up) CDi = busy) from le- 
vel 1 is satisfied in M2. In the module Mi, there is only one state such 
that PosCDi = Down and there is no successor. We then conclude that 
PosCDi = Down A Q{PosCDi = Up) is false and globally Pi^ is satisfied. 
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Fig. 13. The second refined transition system 



— Pi^=U[PosCDi = UpA Q{PosCDi = Down) ^ CDi = free) from level 
1 is satisfied in Mi. We use the same reasoning than Pi^. 

— P2i=n(CP2 = busy CD2 = busyU{CD2 = busy A ED2 = free)) defined 
on level 2 is satisfied modular ly on and on Mg. In the other modules 
M[ and we have □(C'I?2 = free). We then conclude that P21 is globally 
satisfied. 



6 Conclusion 

We propose a technique that allows the modular verification of a class of usual 
dynamic properties of reactive systems. These properties are safety and liveness 
properties, and they are checked by means of a model-checker. The main problem 
in applying this technique based on reachability analysis is the potential combi- 
natorial explosion of the state space. In order to attack this problem, we define 
a strategy based on local verifications which uses the refinement process. From 
the abstract specification of a P event system, we derive a detailed specification 
by introducing news events. We then look at the new properties that have to be 
checked on the chains of new events. These properties are verified on modules 
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rather than on the whole transition system, and consequently the verification of 
a PLTL property reduces to the verification of a local PLTL property. 

For some specific dynamic property patterns, we have exhibited sufficient 
conditions to assert that if a PLTL property is satisfied on each module, then 
it is globally satisfied. The negations of these modular properties are recognized 
by particular Biichi automata that we describe. However, in some cases, if the 
verification of the property fails on a module, we cannot conclude about the 
satisfaction of this property. This situation is possibly due to the fact that the 
property should have been established at an abstract level of abstraction because 
it uses a chain of old events. This point has already been discussed and published 
at the Conference IFM’99 in York [14]. 

We have shown in [19] another possibility to reduce the complexity of ve- 
rification by model-checking for large systems which consists of a combination 
of model-checking and theorem-proving techniques. Patterns in the shape of 
□ (p => Q) can be studied in two verifications. Invariance properties O-ip can be 
verified with the prover and temporal properties <0>p A n(p Q) with a model- 
checker. Then, there are two kinds of modules: those in which we have D-ip and 
those in which some states verify p. In the first case, the B prover is the proper 
tool for provingD-ip. Thus, the modules are treated separately without commu- 
nication. In practice, we are working at the implementation of a verification tool 
using both the B and SPIN environments. 

The work that we present in this paper only uses the syntactic way to cha- 
racterize the modular dynamic properties, without taking into account their 
semantics. The modular class is formed of patterns in the shape of n(p Q), 
where p is a proposition and Q is a temporal formula such as Qq, ^q, and qUr. 
We project in future research to extend this class of properties by using the 
semantics level of the specification. We know that a module is exited with tran- 
sitions that correspond to the occurrence of old events. The idea is to use this 
information in order to prove that some properties (not in BA 2 ) are modular in 
the very context of such a semantic modular split. This class of PLTL properties 
could combine many different temporal operators. 



References 

1 . J.-R. Abrial. The B Book : Assigning Programs to Meanings. ISBN 0521-496195. 
Cambridge University Press, 1996. 

2. J. R. Abrial and L. Mussat. Introducing dynamic constraints in b. In Second 
Conference on the B method, France, LNCS 1393, pages 83-128. Springer Verlag, 
April 1998. 

3. A. Arnold. Systemes de transitions finis et semantique des processus communicants. 
Masson, 1992. 

4. A. Arnold and S. Brlek. Automatic verification of properties in transition systems. 
Software-Practice and Experience, 25(6):579-596, 1995. 

5. F. Bellegarde, J. Julliand, and O. Kouchnarenko. Ready-simulation is not ready to 
express a modular refinement relation. In Proc. Int. Conf. on Fondamental Aspects 
of Software Engineering, EASE’2000, volume 1783 of Lecture Notes in Computer 
Science, pages 266-283. Springer- Verlag, April 2000. 



Modular Verification for a Class of PLTL Properties 



419 



6. C. Courcoubetis, M. Vardi, P. Wolper, and M. Yannakakis. Memory efficient al- 
gorithms for the verification of temporal properties. Formal Methods in System 
Design, 1:275-288, 1992. 

7. Cuellar, I. Wildgruber, and D. Barnard. Combining the design of industrial systems 
with effective verification techniques. In FME’94, LNCS n. 873, pages 639-658. 
Springer Verlag, 1994. 

8. P. Godefroid. Partial-order methods for the verification of concurrent systems. 
LNCS, 1032, 1996. 

9. P. Godefroid and G.-J. Holzmann. On the verification of temporal properties. In 
PSTV’93, June 1993. 

10. G.-J. Holzmann. Design and validation of computer protocols. 1991. 

11. G.-J. Holzmann. The model checker spin. In IEEE Trans. On Software Enginee- 
ring, volume 23, 1996. 

12. G.-J. Holzmann. State compression in spin. In 3’^'* SPIN Workshop, Twente 
University, April 1997. 

13. H. Hungar. Combining model checking and theorem proving to verify parallel 
processes. In C. Courcoubetis, editor, 5th International Conference on Computer 
Aided Verification: CAV’93, number 697 in LNCS, Elounda, June/July 1993. 

14. J. Julliand, P.A. Masson, and H. Mountassir. Modular verihcation of dynamic 
properties for reactive systems. In International Workshop on Integrated Formal 
Methods (IFM’99), pages 89-108, York, UK, June 1999. Springer Verlag. 

15. K. Laster and O. Grumberg. Modular model-checking of software. In TACAS’98, 
Lisbon, March-April 1998. 

16. Z. Manna and A. Pnuelli. The Temporal Logic of Reactive and Concurrent Systems: 
Specification. ISBN 0-387-97664-7. Springer- Verlag, 1992. 

17. Z. Manna and A. Pnuelli. Temporal verification of reactive systems. ISBN 0-387- 
94459-1. Springer Verlag, 1995. 

18. R. Milner. Communication and Concurrency. Gomputer Science. Prentice-Hall, 
1989. 

19. H. Mountassir, F. Bellegarde, J. Julliand, and P.A. Masson. Cooperation entre 
preuve et model-checking pour verifier des proprietes LTL. In congres AF- 
ADL’2000, Grenoble, December 2000. 

20. D. Peled and W. Penczeh. Using asynchronous biichi automata for efficient verifi- 
cation of concurrent systems. In Symposium on Protocol Specification Testing and 
Verification, pages 90-100, Warsaw, Pologne, June 1995. 

21. D. A. Peled. Combining partial order reduction with on-the-fly model-checking. 
In CAV’94, LNCS n. 818, pages 377-390. Springer Verlag, June 1994. 



Towards Model Checking 
Stochastic Process Algebra 



Holger Hermanns^, Joost-Pieter Katoen^, 

Joachim Meyer-Kayser^, and Markus Siegle^ 

^ Formal Methods and Tools Group, University of Twente, 
P.O. Box 217, 7500 AE Enschede, The Netherlands 
{hermanns I katoenjOcs . utwente . nl 
^ Lehrstuhl fiir Informatik 7, University of Erlangen-Niirnberg, 
Martensstrafie 3, 91058 Erlangen, Germany 
{ jmmeyerk I siegle}@inf ormatik .uni-erlangen. de 



Abstract. Stochastic process algebras have been proven useful because 
they allow behaviour- oriented performance and reliability modelling. As 
opposed to traditional performance modelling techniques, the behaviour- 
oriented style supports composition and abstraction in a natural way. 
However, analysis of stochastic process algebra models is state-oriented, 
because standard numerical analysis is typically based on the calculation 
of (transient and steady) state probabilities. This shift of paradigms ham- 
pers the acceptance of the process algebraic approach by performance 
modellers. In this paper, we develop an entirely behaviour-oriented ana- 
lysis technique for stochastic process algebras. The key contribution is an 
action-based temporal logic to describe behaviours-of-interest, together 
with a model checking algorithm to derive the probability with which a 
stochastic process algebra model exhibits a given behaviour-of- interest. 



1 Introduction 

The analysis of systems with respect to their performance is a crucial aspect in 
the design cycle of concurrent information systems. Although huge efforts are 
often made to analyse and tune system performance, these efforts are usually 
isolated from contemporary hardware and software design methodology [15,18, 
28]. This insularity of performance analysis has numerous drawbacks. Most se- 
vere, it is unclear how to incorporate performance analysis into the early stages 
of a design, where substantial changes are still not too costly. In these design 
stages, system models are nowadays developed by means of semi-formal methods 
such as UML or SDL. 

In order to overcome the insularity problem, there is a growing tendency to- 
wards the integration of performance modelling and analysis into (semi-)formal 
methods, such as Petri nets [1], process algebra [21], or SDL [12]. This inte- 
gration has potential benefits for the application of both formal methods and 
performance analysis: Using a formal method, performance models of interest are 
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readily available for analysis. Conversely, the availability of quantitative insight 
into a design clearly adds extra value to a formal design. 

Process algebra is an influential approach to the modelling of concurrent 
systems using formal methods. Developed in the SOies, process algebra is radi- 
cally behaviour -oriented. Systems are modelled by describing the possible be- 
haviours they can exhibit to the external environment. This approach led to 
powerful composition operators as means to compose behaviours hierarchically. 
The behaviour-oriented approach also enables one to employ abstraction me- 
chanisms to compress behaviours to only those fragments relevant in a specific 
environment. 

In a behaviour-oriented setting, the notion of a state is an auxiliary one. To 
identify a state is of no importance, since a state is completely characterized by 
the behaviour it exhibits. As a consequence, states exhibiting the same behaviour 
are considered to be indistinguishable, and hence are (or can be) collapsed to just 
a single state, using an appropriate notion of equivalence (such as bisimulation). 

During the last decade, stochastic process algebra (SPA) has emerged as a 
promising way to carry out compositional performance and reliability modelling, 
mostly on the basis of continuous-time Markov chains (CTMCs) [21]. Following 
the same philosophy as ordinary process algebra, the stochastic behaviour of 
a system is described as the composition of the stochastic behaviours of its 
components. 

However, all standard analysis algorithms for stochastic models are purely 
state-based. They compute interesting information about the model on the basis 
of state probabilities derived by either transient or steady-state analysis [35] . As 
a consequence, there is a disturbing shift of paradigms when it comes to the 
analysis of stochastic process algebra models: While the model is specified in 
a behaviour-oriented style, the performance properties-of-interest are defined in 
terms of states, on a very different level of abstraction. This shift of paradigms 
clearly hampers the acceptance of the SPA approach to performance modellers. 

In the context of model checking of ordinary (i.e. non-stochastic) process al- 
gebra models, a similar mismatch has been attacked successfully. Model checking 
is a successful technique to establish the correctness of a given model, relative to 
a set of temporal logic properties which the model should satisfy [9,10]. The most 
efficient model checkers use the logics LTL or CTL. Though different in nature, 
both logics are state-oriented, their basic building blocks are state propositions. 
So, at first sight they do not fit well to a behaviour-based formalism. 

To import the success of model checking to behaviour-oriented formalisms, 
De Nicola and Vaandrager have pioneered the development of an action-based 
variant of CTL, called aCTL [33,34]^. aCTL is behaviour-oriented, yet it na- 
turally corresponds to CTL. In particular, [33,34] provide a translation from 
aCTL to CTL that allows one to perform (behaviour-oriented) aCTL model 
checking by means of a (state-oriented) CTL model checker (on a transformed 



^ The logic aCTL should not be confused with the logic ACTL, the restriction of 
CTL to universal path quantifiers. 
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model) with only linear overhead. (It should however be noted that direct aCTL 
model checkers are more popular by now [14,32].) 

In this paper, we develop a behaviour-oriented analysis technique for CT- 
MCs, and hence for the SPA approach modelling and analysis become entirely 
behaviour-oriented. This is the central contribution of the paper. Our analysis 
complements behaviour-oriented CTMC modelling with SPA in the same sense 
as De Nicola and Vaandrager’s work complements ordinary process algebraic 
modelling. 

We develop an action-based, branching-time stochastic logic, called aCSL 
(action-based Continuous Stochastic Logic), that is strongly inspired by CSL, 
the continuous stochastic logic first proposed in [2] and further refined in [5,3]. 
Similar to CSL, aCSL provides means to reason about CTMCs, but opposed to 
CSL, it is not state-oriented. Its basic constructors are sets of actions, instead 
of atomic state propositions. The logic provides means to specify temporal and 
timed properties, and means to quantify their probability. aCSL allows one to 
specify properties such as “there is at least a 30% chance that action SEND will 
be observed within at most 4 time units”. After defining syntax and semantics, 
we develop a dedicated model-checking algorithm for aCSL. As an application 
example, we study behaviour-oriented performance and reliability properties of a 
multiprocessor mainframe example taken from [23]. Furthermore, we show that 
Markovian bisimulation, an equivalence notion that can be used to compress 
SPA specifications compositionally, preserves aCSL-formulas. This property is 
exploited in our case study. 

For efficiency reasons, our model checking algorithm is not based on a trans- 
lation from aCSL to CSL. Instead, it checks aCSL properties directly. A trans- 
lational approach would allow one to use a state-based CSL model checker (such 
as E I— MC^ [24]), but with an increase of the state space. We briefly sketch the 
translation from aCSL to CSL, which is inspired by Emerson and Lei [13], and 
discuss why the linear translation in the style of De Nicola and Vaandrager [33, 
34] fails in the stochastic setting. 

The paper is organised as follows. Section 2 introduces action-labelled Mar- 
kov chains, the basic model considered in this paper. In Section 3, we define 
syntax and semantics of aCSL, derive a number of convenient operators, and 
discuss Markovian bisimulation. Section 4 focuses on model checking of aCSL. 
Section 5 studies aCSL-properties of the multiprocessor example, while Section 

6 briefly discusses the translational approach to model checking aCSL. Section 

7 concludes the paper. 



2 Action-Labelled Markov Chains 

The operational semantics of purely^ Markovian process algebra such as 
TIPP [16], PEPA [29] and (the core of) EMPA [7] is defined in terms of la- 
belled transition systems where transitions are labelled with pairs of actions and 

^ We call a stochastic process algebra purely Markovian if the delay of any action is 
governed by an exponential distribution. 
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rates. In this section we briefly recall this notion and define some notations that 
are convenient for our purpose. 



Action-labelled Markov chains. Let Act denote a set of actions, ranged over 
by a, b. We will use A, B as subsets of Act and adopt the convention that for 
singleton sets curly brackets are omitted; i.e., we write a for {a}. 

Definition 1. An action-labelled Markov chain (AMC) Ai is a triple 
{S,A, — >•) where S is a set of states, A C Act is a set of actions, and 
— ^ Q S X (A X 5?>o) X S is the transition relation. 

Throughout this paper we assume that any AMC is finite, i.e., has a finite number 
of states and is finitely branching. Transition s > s' denotes that the system 
can move from state s to s' while offering action a after a delay determined by 
an exponential distribution with rate A. We use the following notations: 

R-a(s, s') = ^{A I s-^s'} 

aGA 

E(s) = ^ Raci(s, s') 
s'es 

Pa(s,s') =Ra(s,s')/E(s). 

Stated in words, Ra(s, s') denotes the cumulative rate of moving from state 
s to s' while offering some action from A, E(s) denotes the total rate with 
which some transition emanating from s is taken, and finally, Pa(s,s') is the 
probability of moving from state s to s' by offering an action in A. For absorbing 
s, E(s) = 0 and Pa(s, s') = 0 for any state s' and any set A. Further note that 
R^(s, s') = P 0 (s, s') = 0 for any states s, s'. 



Paths. An infinite path ct is a sequence sq > si > S2 > . . . with 
for i G IN, Si G S, Qi G Act and ti G IR>o such that R^. (si, s^+i) > 0. For i G IN 
let a[i] = Si, the (i-l-l)-st state of cr, and 5(a,i) = ti, the time spent in s^. For 
t G and i the smallest index with t ^ ~ state in 

cr at time t. 

A finite path cr is a sequence sq - °°’* - > si > S 2 . . . s;_i > sj where 

Si is absorbing, and R(sj, s^+i) > 0 for all i < 1. 

For finite a, a[i] and d{a,i) are only defined for i Gi t, they are defined as 
above for i < I, and 6{a,l) = oo. For t > a@t = sp, otherwise, a@t 

is as above. 

We denote (j[i] ^^cr[i-|-l] whenever a[i] can move to cr[i-|-l] by performing 
some action in A, i.e., if Oi G A. Note that cj[i] . Let Path{s) denote the set 
of paths starting in s. A Borel space over Path(s) can be defined in a similar 
way as in [5] and is omitted here. 
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3 An Action-Based Continnous Stochastic Logic 

This section describes the action-based stochastic logic aCSL which is inspired 
by the action-based logic aCTL by De Nicola and Vaandrager [33] and the 
stochastic logic CSL by Baier et al. [5], which in turn is based on the work of 
Aziz et al. [ 2 ]. 



3.1 Syntax and Semantics of aCSL 

Syntax. For p G [0, 1] and ix] G { ^, <, ^, > }, the state-formulas of aCSL are 
defined by the grammar 



<l> ::= true 



^ A 






i^ixip (^) 



Mp (^) 



where path-formulas are defined for t G IR>o U { oo } by 



(p ::= 






Note that atomic propositions are absent. The boolean connectives such as V and 
=> are derived in the obvious way. The probabilistic operator Pixip(.) replaces 
the CTL path quantifiers 3 and V that can be re-invented — up to fairness [6] — 
as the extremal probabilities P>o (.) and (.). The state formulas are directly 
adopted from CSL: (^) asserts that the steady-state probability for a ^- 

state meets the bound txip and P^p (p) asserts that the probability measure of 
the paths satisfying p meets the bound txi p. 

The path-formula ^2 is fulfilled by a path if a ^2-state is eventually 

reached via visiting only ^i-states before, while taking only A-transitions; be- 
sides, going from the beginning of the path until reaching the ^2-state should 
last at most t time units. The formula b ^2 requires in addition that 

(i) a move to a ^2-state is actually made and that (ii) this transition is label- 
led by some action in B. We remark the following. Due to the fact that the 
<?2-state must be reached via a i?-transition, the formula ^2 is invalid 

in a A <?2)-state s: although the state satisfies <?2, it is not able to move 
from a ^i-state to a ^2-state via a B-transition as it does not fulfill <Pi. The 
formula ^2 is, however, valid in state s, since for the validity of this for- 

mula it is not required that a transition into a <?2~state is made. Thus, whereas 
for <Pi ^2 it suffices to currently be in a <?2-state, this is not the case for 
aU<^b<^2-^ 

^ If we enlarged the set of path-formulas such that conjunction and negation of path- 
formulas is allowed (in a similar way as for CTL*), the relationship between b 
and aW'^ could be made precise as follows: 



aW*'* ^2 = ^2 V (^1 aU"'^ A ^ 2 ). 
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The major differences with a ‘standard’ until-formula U <p2 of linear and 
branching temporal logics are that restrictions are put on (i) the action labels 
of transitions to be taken and on (ii) the amount of time that is needed to reach 
a ^2-state. This can be made precise in the following way: 

<PlU<p2=-Pl 

In the sequel, we use aUb ^2 as an abbreviation of aU^°° b ^2 and 
<P\a1^^2 as an abbreviation of These are the untimed versions 

of the until-operators aU''*' b and aW^^ ■ 

An interesting aspect of aCSL is that the following set of next-operators are 
all derived operators: 

(p = true 0W^*A^ 

Xa^ = X<°°<!> 

X<P = XAct^*- 

The formula X^* (p asserts that from the current state an A-transition can be 
made to a <?-state before time t. Remark that the <?-state must be reached by 
the first transition, as — due to the empty set of actions — further transitions 
are disallowed. Xa is the action-labelled next-operator from aCTL, whereas X 
is the traditional state-based next-operator. 

Note 1 . In our logic, the next operator is derived from the until-operator. In 
aCTL the reverse holds [33]. This stems from the special treatment of inter- 
nal, i.e., r-labelled, transitions in aCTL. For instance in aCTL, X0<P allows 
to reach a <?-state by an internal transition (but not any other). In our setting, 
internal transitions are treated as any other transition, and accordingly, X0 <!> is 
invalid for any state. We have made this difference deliberately: whereas aCTL 
is aimed to characterize branching bisimulation - a slight variant of weak bisimu- 
lation equivalence - we focus on characterizing a strong equivalence like lumping 
equivalence (since exact weak equivalences on AMCs cannot be obtained [ 21 ]). 

The temporal operator O and its variants are derived in the following way: 

aO^* 4 > = true ^ 

aO <P = ^ 

0<t<p = 

A path fulfills if it reaches a ^-state within t time units by only per- 
forming A-actions. Formulas a^ ^ and denote the generalisations to in- 

finite time and arbitrary actions. Their combination, O corresponds to the 
well-known “eventually” operator. An even more discerning O-operator can be 
defined by 

A^g*<P = true aU^^b ^ and a'^b^ = a'^b°° ^ 

Here, the path leading to the ^-state consists of an arbitrary number of A- 
actions, followed by a single B-action. Dual to these O-operators is the set of 
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□-operators, of which we only mention the following: 

= -'T^cxp and V^p {a<>b*~''^) 

with the obvious generalisations to infinite time and/or arbitrary sets of actions. 
Finally, existential and universal quantification are introduced as 

3tf = Vyo i^) and V(p = V^i {(p) 



Note that by this definition formula \/(p holds even if there exists a path that 
does not satisfy p, if that path has zero probability mass. 

We consider the modal operators from Hennessy-Milner logic [19] and the 
/x-calculus [30] as derived operators. They are obtained as follows: 

(A) $ = r >0 {Xa and [A] ^ = ^{A) 



The modal operator (A) states that there is some A-transition from the current 
state to a ^-state, whereas [A\ (p states that for all A-transitions from the current 
state a ^-state is reached. 



Note 2. The modal operator (a)p <P from the probabilistic modal logic PML [31] 
cannot be obtained as a derived operator in our setting. The state-formula {a)p <P 
asserts that, given that an a-transition happens, the probability of moving to 
a ^-state is at least p. This interpretation fits well to the reactive probabilistic 
setting used in [31] in which over each set of equally labelled transitions a discrete 
probability space is defined. Since we consider a generative setting — having a 
discrete probability space over all, possibly different labelled, transitions — the 
probability in a formula like {a)p <P is relative to all transitions, and not just the 
ones labelled with a. In the continuous variant of PML [8] a similar approach 
as in [31] is taken, and a reactive interpretation is used. 



Semantics. The aCSL state-formulas are interpreted over the states of an AMC 
{S,A, -a). Let Sat{^) = {s G S \ s^P>}. 



s ]= true for all s £ S' 
s ]= iA s 



s \= <Pi t\ <p2 

S ^ S|xip (^*) 
S \= 'P xp (jp) 



iff s ^ for i=l, 2 
iff 7t(s, Sat{(P)) t<i p 
iff Prob(s, p) txip 



Here, 7t(s, S') denotes the steady-state probability to be in a state of set S' when 
starting in s. It is defined by means of a probability measure^ Pr on the set of 
paths Path{s) emanating from s. 



7t(s, s') = lim Pr{ cr £ Path{s) \ cr@t G S' } 

t—¥oo 



Prob{s, p) denotes the probability measure of all paths satisfying p given that 
the system starts in state s, i.e.. 



Prob{s,p) = Pr{ cr £ Path{s) \a \= p}. 

^ The probability measure Pr is defined by means of a Borel space construction on 
paths. We refer to [5] for a formal definition. 
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The fact that these sets are measurable follows by easy verification from the 
Borel space construction given in [5] . 

The meaning of the path-operators is defined by a satisfaction relation, also 
denoted by between a path and a path-formula. We define: cr ^ ^2 

if and only if: 

3k ^ 0. (^cr[k] ^ <1>2 

<k.a[i]\= (l>i a[i+l]) /\ t >Y^IZq 

where we recall that 5{a,i) denotes the sojourn time in state cr[i\. Thus, 
^2 is valid for a path if at some time instant before t a <? 2 -state is 
reached — assume this is the (fc-l-l)-st state (for fc ^ 0) in the path so far — by 
visiting only <?i-states, while taking only A-transitions along the entire path. 
For the other until-formula we have: a \= b ^2 if and only if: 

3k > 0. {a[k] 1= i ?2 A (V* < k—\. a[i] |= A cr[i] ct[z-|-1]) 

A a[k—l] \= <Pi A cr[fc— 1] a[k] A t > J2iZo *)) 

Note the subtle difference with (1): For <Pi b ^2 to be valid, there should 
be a single transition leading to a i? 2 -state labelled by some action in B. 

It is left to the interested reader to check that s ^ <P iff 

cr[l] \= (p A (t[0] a[l] A t > (5(cr, 0). 

This agrees with the intuitively expected semantics for 

3.2 Markovian Bisimulation 

In this section, we show that aCSL is invariant under the application of Marko- 
vian bisimulation. Markovian bisimulation, a variant of Larsen-Skou bisimulation 
[31], is a congruence for the stochastic process algebras TIPP [16] and PEPA 
[29]. In the context of process algebraic composition operators, a congruence 
relation can be used to compress the state space of components before composi- 
tion, in order to alleviate the state space explosion problem, under the condition 
that the relation equates only components obeying the same properties. Hence 
the question arises whether a Markovian bisimulation R can be applied to com- 
press models (or model components) prior to model checking aCSL-formulas. 
In general, this requires that the validity of aCSL-formulas is preserved when 
moving from an AMC Ai to its quotient AMC M.jR. We establish this property 
in Theorem 1. 

Definition 2. A Markovian bisimulation on At = (S', A, — > ) is an equivalence 
R on S such that whenever (s,s') € R then Rq(s,C) = Ra(s',C) for all C € 
S/R and all a € Act. States s and s' are Markovian bisimilar iff there exists a 
Markovian bisimulation R that contains (s, s'). 
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Here, S/R denotes the quotient space and Rq(s, C) abbreviates X^s'gC Ra(s,s'). 
Let M/Rhe the AMC that results from building the quotient space of Ai under 
i?, i.e., M.jR = {SjR, A, — >■ ). In the following we write \=m for the satisfaction 
relation \= (on aCSL) on Ai. 

Theorem 1. Let R be a Markovian bisimulation on M and s a state in M. 
Then: 

(a) For all state-formulas T>: s |=^ F iff \=MjR ^ 

(b) For all path-formulas (p: Prob‘d {s,ip) = Prob'^^ ^{[ s]r,lp) . 

In particular, Markovian bisimilar states satisfy the same aCSL formulas. 

In the appendix, we sketch the proof of Theorem 1. The detailed proof can be 
found in [25]. This result allows to verify aCSL- formulas on the potentially much 
smaller AMC Ai/R rather than on Ai . The quotient with respect to Markovian 
bisimilarity can be computed by a modified version of the partition refinement 
algorithm for ordinary bisimulation without an increase in complexity [26]. In 
addition, due to the congruence property of Markovian bisimularity on TIPP 
and PEPA, a specification can be reduced in a compositional way, thus avoiding 
the need to model check the (possibly very large) state space S. This feature is 
exploited in the case study discussed in Section 5. 

4 Model Checking aCSL 

The general strategy for model checking aCSL proceeds in the standard way: For 
a given state formula F, the algorithm recursively computes the sets of states 
satisfying the sub-formulas of F, and constructs from them the set of states 
satisfying F. For boolean connectives, the strategy is obvious. Model checking 
steady-state properties S^p {F) involves solving linear systems of equations, after 
determining (bottom) strongly connected components, exactly as in the CSL 
context [5]. 

Model checking the probabilistic quantifier V^p (<p) is the crucial difficulty. 
It relies on the following characterizations of Prob{s, (p). We discuss the charac- 
terizations by structural induction over p. For the sake of simplicity, we first 
treat the simple untimed until-formulas. 

Untimed until. For p = F 1 AUF 2 we have that Prob{s,p) is given by the 
following equations: Prob{s,p) = 1 if s ^ F 2 , 

^ Pa(s,s') ■ Prob{s',p) 
s'es 

if s \= Fi A -'F 2 , and 0 otherwise. For A = Act we obtain the equation for 
standard until as for DTMCs [17]. 

Let p = Fi aHbF 2 . For s [A the formula is invalid. As for s \= F\ the 
situation is more involved let us, for the sake of simplicity, assume that A and 
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B are disjoint, i.e. Ap\ B = 0 . Then the only interesting possibilities starting 
from s are (i) to directly move to a <^2-state via a i?-transition, in which case the 
formula tp is satisfied with probability 1, or (ii) to take an A-transition leading 
to <?i-state s' which satisfies <p with probability Prob{s' ,(p). Accordingly, for 
An B = 0 , Prob{s, (p) can be characterized by: 



^ Pb{s,s')+ ^ Pa{s,s') ■ Prob{s',p). 

s' 1=^2 s'|=<Pi 



( 2 ) 



In the general case we have to take into account that A and B may not be 
disjoint. Equation (2) does not apply now, since an (A n S)-transition into a 
state that satisfies both <?i and is “counted” twice. We therefore obtain that 
Prob{s, p) is the least solution of the following set of equations: 



E 

s' 1=^2 



E 

s'|=^ 



Pb{s, s') + Pa(s, s') • Prob{s', p) - 



E 

s'|=^iA ^2 



PAns(s, s') • Prob{s',p) 



if s ^ ^1, and 0 otherwise. Note that 

Prob{s,XB^) = Prob{s,t'Tue zUb^) = 



s'\=<P 



Pb(s,s') 



which coincides, for B — Act, with the characterization of next for DTMCs [17]. 
Thus, the probability that s satisfies Xb’I’ equals the sum of the probabilities 
to move to a <P-state via a single B-transition. The reader is also invited to 
check that for i? = 0 there is no state that satisfies aUb ^2 with positive 
probability. 



/■ 



Timed until. For ip = ^2 we have that Pro6(s, p') is the least solution 

of the following set of equations: Prob{s^ p) = 1 if s \= ^2, and 

pt 

g-E(s).x, ^yIa{s,s') ■ Prob{s' ^2) dx 

s'es 

if s ^ A-'^2, and 0 otherwise. For state s satisfying A -'^2, the probability 

of reaching a <?2-state within t time units from s equals the probability of reaching 
some direct successor s' of s within x time units, multiplied by the probability of 
reaching a <?2-state from s' within the remaining time t—x. Since there may be 
different paths from s to ^2-states, the sum is taken over all these possibilities. 
(Note that by taking t = 00 we obtain, after some straight-forward calculations, 
the characterisation for imtimed until Aid given before). 

For p = <Pi aU^'b d’2 we have that Prob{s, p) is the least solution of the 
following set of equations: 



„-E(.).x, ( ^ Rs{s,s')+ Yi RAis,s')-Prob{s',$iAU<^-^B 



<^2) 



^ RAnB{s,s')-Prob{s',^iAld<^-^ 



s'|=^iA^2 



B‘^2) dx 
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if s \= ^ 1 , and 0 otherwise. This characterization can be justified in the same 
way as for its untimed counterpart, i.e., aUb ^ 2 , given the above explanation 
for the simpler timed until variant. Let us consider what this yields for X^^'P: 



Prob{s,Xg'^ (p) = Prob{s,true 0 lAg^ <P) = f e 

Jo 

which, after some straight-forward calculations, leads to 

s'l=<P 



s'\='P 



The first term of the product denotes the discrete probability to move via a single 
B-transition to a ^-state, whereas the second term denotes the probability to 
leave state s within t time units. 

This equational characterization allows one to model check aCSL formulas 
by means of approximate numerical techniques. The concrete implementation 
closely follows the one for CSL outlined in [5] and implemented in [24]. We are 
currently investigating whether the solution of the above integral equations can 
be reduced to standard transient analysis via uniformisation, as in [3]. 



5 Case Study 

We consider a multiprocessor mainframe which was first introduced in [27] and 
has since then served as a standard SPA example, see e.g. [23,11]. Here we only 
briefly repeat the main features of the model. 



5.1 Specification of Multiprocessor Mainframe 

The multiprocessor mainframe serves two purposes: It has to process database 
transactions submitted by users, and it provides computing capacity to program- 
mers maintaining the database. The system is subject to software failures which 
are modelled as special jobs. On the top level, the system is composed of two 
processes (cf. Fig. 1). 

System := Load\[putUserJob,putProgJob, fail] \ Machine 

Process Load represents the system load caused by the database users, the pro- 
grammers and the failures. The mainframe itself is modelled by the Machine 
process. The three different system load components are modelled as so-called 
Markov modulated Poisson processes, see [27]. The intensity of the load alters 
between different levels. To realize a synchronous change of load level, a syn- 
chronizing action c is used. 

Load := ProgLoad |[c]| User Load |[c]| FailLoad 
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Fig. 1. Mainframe model structure 



The Machine component consists of two finite queues and four identical pro- 
cessors. The queues buffer incoming jobs. They are controlled by a priority me- 
chanism to ensure that programmer jobs have the lowest priority, while failures 
have the highest priority. The priority mechanism is realised by appropriate syn- 
chronisation of the queue processes. For instance, process Q can only deliver a 
job to a processor if queue R is empty and no failure is present. Furthermore, 
the insertion of new jobs into the system is prohibited once a failure has occured, 
until the system is repaired. 

Each of the four processors executes user or programmer jobs waiting in the 
respective queues, unless a failure occurs. As failures have preemptive priority 
over the other two job classes, all processors stop working once action fail has 
occured and then wait until the system will recover (via action repair). 

5.2 Properties of Interest 

This section contains some example properties which are of interest for the mul- 
tiprocessor mainframe model. For each property, a description in plain English, 
its aCSL formulation and some explanation are given. We first introduce some 
purely functional requirements to ensure that the priority mechanism is pro- 
perly realised by the model. Then we turn to the performance and reliability 
requirements which the system should satisfy. For A C Act we let A denote 
Act\ A. We use the following sets of actions: Get := {getUserJob,getProgJoh}, 
Put := {putUserJob,putProgJob}, Fin := {finishU serJob, finishProgJob} 
and FailRep := {fail, repair}. We omit brackets for singleton sets. 

<l>i: If there are user jobs waiting, the processors will not start programmer jobs. 

^UserjobWaiting ^ ^{getProgJob) true 

where <PuserjobWaiting is defined by 3 { p^tUserjob ^g^tUserjob true), charac- 
terizing at least one user job waiting in the queue. 
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<l>2- Whenever a failure occurs, no jobs can be inserted into the queues until the 
system is repaired. 

[/nz/] V (p^t^repazr^^'^c) 

<^3: Whenever a failure occurs, the processors will be blocked until the system 
is repaired. 

[fail] V (cetu pin'^repairtrue) 

<^4: After a repair, both queues are empty. 

[repaiv] ( ^UserJobWaiting ^ ^ Prog JobW ailing ) 

where ^progjobWaUmg characterizes at least one waiting programming job, 
defined in a similar way as ^’userjobWaiUng- This is an example of a property 
which is not true, since a failure does not cause the queues to be flushed. 

<^5: In steady state, the probability of low priority programming jobs having to 
wait because of user jobs being served is smaller than 0.01. 

S<Q,oi{{finishUserJob)true A <PprogjobWaiUng) 

<Pq: At least two processors are occupied by user jobs. 

(finishUserJob) (finishUserJob) true 

•Pr: In steady state, the probability that at least two processors are occupied by 
user jobs is greater than 0.002. 

5>o.oo2 { Pe ) 

Ps- There is at least a 30% chance that some job will be finished within at most 
4 time units. 

'P^o.s {-FlKO^Ltrue) 

Pg: In steady state, the probability of the system being unavailable (i.e. waiting 
for repair) is at most 0.05. 

5^0.05 (^{pailRep^repairtrUe)^ 

PiQi After a system failure, there is a chance of more than 90% that it will come 
up again within the next 5 time units. 

[fail] Vyg.g 

The fact that the above property holds for all states can be expressed by V □ ^10 . 

Slightly weaker, one might require the above property to hold on the long run, 

formulated as S-^i (^10). 
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Table 1. Verihcation runtimes 



states (original) 


3690 


13530 


110946 


(compressed) 


720 


2640 


21648 



property 


verification runtimes (in 


seconds) 


^1 


0.012 


0.037 


0.268 


^2 


0.008 


0.049 


0.864 


^3 


0.008 


0.039 


0.319 




0.003 


0.005 


0.036 


<^5 


0.642 


2.371 


18.750 


^6 


0.001 


0.002 


0.014 


^7 


0.558 


2.122 


18.814 


<Pg 


0.554 


2.009 


18.819 


4^10 


2.557 


11.404 


92.324 



5.3 Verification Results 

In this section we report on our experience with the verification of the above 
properties. The results have been obtained by means of a trial implementation, 
basically an extension of the model checker E I— MC^ [24]. The implementation 
does not yet support the full logic aCSL, therefore property has not been 
checked. 

For the properties listed in the previous section we present the verification 
runtimes in Table 1. We checked three models: A small model with 4 (2) pro- 
grammer (user) buffer places, an intermediate model with 10 (4) programmer 
(user) buffer places and a large model with 40 (10) programmer (user) buffer 
places. The small model has 3690 states and 24009 transitions, the intermediate 
model has 13530 states and 91069 transitions and the large model has 110946 
states and 761989 transitions. However, we did not perform model checking on 
the original models but on models with compressed state spaces which we gained 
through the application of Markovian bisimilarity (in the example multiproces- 
sor system, the main potential for reduction stems from the symmetry of the 
four identical processors). By Theorem 1, the compressed models satisfy the 
same properties as the original ones. After bisimilarity compression, the small 
model has 720 states and 3219 transitions, the intermediate model has 2640 
states and 12295 transitions and the large model has 21648 states and 103471 
transitions. All steady state properties given in the table were double checked 
with TIPPtool [22]. 
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6 On Translating aCSL to CSL 

The design of aCSL closely follows the work of De Nicola and Vaandrager on 
aCTL [33]. For what concerns model checking, they propose a translation K. 
from aCTL into CTL, and a transformation (also denoted K.) from action- 
labelled to state-labelled transition systems in such a way that for an arbitrary 
aCTL formula and arbitrary action-labelled transition system M. (with the 
obvious notation): 



iff K(^),CTL (3) 

In this way, aCTL model checking can be reduced to CTL model checking, 
by checking a translated formula /C(^) on a transformed model /C(A4). The 
bypass via /C blows up the model and the formula, but only by a factor of 2, 
whence it follows that model checking aCTL has the same worst case (space 
and time) complexity as CTL. The key idea of this transformation is to break 
each transition of M in two, connected by a new auxiliary state. The new state 
is labelled with the action label of the original transition, playing the role of 
an atomic state proposition. (The original source and target states are labelled 
with a distinguished symbol T). Formula is manipulated by /C in such a way 
that starting from some state JC{s) essentially all the labellings of original states 
(T) do not matter, while the ones of auxiliary states do. Unfortunately, this 
approach does not carry over to the Markov chain setting, because splitting a 
Markovian transition in two implies splitting an exponential distribution in two. 
However, no sequence of two exponential distribution agrees with an exponential 
distribution. Since aCSL is powerful enough to detect differences in transient 
probabilities, this approach is infeasible. 

Even though a translation in the style of De Nicola and Vaandrager does not 
allow one to reduce aCSL to CSL, this does not imply that such a reduction 
is generally infeasible. For the sake of completeness, we remark that it is indeed 
possible to reduce model checking aCSL to model checking (slight variants of) 
CSL. We briefly sketch two possibilities: 

— Apply the transformation of [33] and map AMCs to interactive Markov 
chains (IMG) [20]. This transformation is exemplified in Figure 2 (from left 
to middle), where state labellings appear as sets, and dashed transitions are 
supposed to be immediate. In general, IMG allow for nondeterminism, but 
this phenomenon is not introduced by the translation. Therefore, the model 
checking algorithm of [5] can be lifted to this subset of IMG. 

— Transform AMGs to state-labelled GTMGs (SMG), using a transformation 
inspired by Emerson and Lei [13]. The main idea is to split each state into 
a number of duplicates, given by the number of different incoming actions 
it possesses, and label each duplicate with a different action, and distribute 
the incoming transitions accordingly. (In order to track the first transition 
delay correctly, one additional T-labelled duplicate per state is needed.) To 
give an intuitive idea, this transformation is depicted in Figure 2 (from left 
to right). A mapping /C from aCSL to a minor variant of CSL exists that 
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Fig. 2. Transformation example from AMC (left) to IMC (middle) and SMC (right) 



ensures s \=m </> to hold if and only if (s, _L) Af (</>) holds. (The 

satisfaction relation \=k{m) CSL requires a subtle - but straight-forward 
to implement - modification.) Details can be found in [25]. In the worst 
case, the state space is blown up by a factor given by the maximal number 
of distinct actions entering a state. 

Notice that both translations sketched above require a small modification of the 
model checking algorithm for CSL [3,5]. Furthermore, both approaches induce 
a blow up of the model by a linear factor. To avoid these drawbacks, we have 
decided to develop a direct model checking algorithm, as sketched in Section 4. 
Remark that despite the aforementioned translations from aCTL to CTL, de- 
dicated model checkers for aCTL are more popular by now [14,32]. 

7 Concluding Remarks 

This paper has introduced a behaviour-oriented analysis approach for Markovian 
stochastic process algebra. From a conceptual as well as from a pragmatic point 
of view, this approach closes a disturbing gap in the process algebraic approach to 
performance and dependability modelling. In particular, performance engineers 
are no longer confronted with the need to switch from a behaviour-oriented to 
a state-oriented view when it comes to model analysis. 

The behaviour-oriented modelling and analysis approach outlined in this pa- 
per has four ingredients: (1) A standard stochastic process algebra (such as 
TIPP, PEPA, EMPA) is used to model the system under consideration as an 
action-labelled CTMC. (2) The action-based logic aCSL serves as a powerful 
means to specify properties of interest. (3) A model checking algorithm decides 
which properties are satisfied by the Markov chain model. (4) Since Markovian 
bisimilarity preserves aCSL properties, it can be used to compress the model 
(or the model components, due to the congruence property for TIPP and PEPA) 
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before model checking. We have illustrated all four ingredients by means of the 
multiprocessor mainframe case study. 

PML^ [8], the continuous-time variant of PML [31], is another logic on 
action-labelled CTMCs. PML^ and aCSL are incomparable, because PML^ 
takes a reactive point of view, while our view is generative (see Note 2). PML^ is 
not considered in the context of model checking, instead it serves as the founda- 
tion of a formalism to assign rewards to states, i.e., to construct Markov reward 
models. The thus obtained models are then analyzed with standard (steady- 
state) numerical analysis. PML^ does neither provide means to quantify pro- 
bability nor to reason about time intervals. 

For the future, we intend to study to what extent aCSL can be extended 
towards the analysis of Markov reward models. In the state-based setting, we 
have recently developed a continuous reward logic (CRL) that allows bounds 
on rewards to be checked, and naturally combines with CSL [4]. 
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A Appendix: Sketch of the Proof of Theorem 1 

In order to verify Theorem 1(a), we prove that {u,v) G R implies V^.(u \=m ^ 
iff V \=M ^)- We do so by structural induction on (p. The only non-trivial cases 
are that is of the form (iZ^), or In the former case, 

we use the induction hypothesis, the fact that Markovian bisimulation implies 
lumpability, and that lumpability ensures that steady-state probabilities can be 
obtained from the lumped quotient Markov chain [21] . In the latter case, Pixip 
we can apply Theorem 1(b), together with the induction hypothesis. So, only 
Theorem 1(b) remains to be verified. For this purpose, it is sufficient to show 
that {u,v) G R implies 

Pr{ cr G Path{u) \ a \= ip} = Pr{ a G Path{v) \ a \= ip} 

We have to distinguish two cases, p = <P\ ^2 and p = <Pi ^ 2 - Only 

the first of them is elaborated below. The other case proceeds in a similar, but 
simpler, way. For n ^ 1 and < > 0 we define the set of paths A“(t) as 

^n(^) = {cr G Path{u) \ cr[n] ^ ^2 

A V 0 ^ i < n. a[i] \= Pi 
A V0<*<n — 1. a[i] (j[i + 1] 

A cr[n — 1] — ^ cr[n] 

A Y.Z^5{a,i)<t} 

(observe the similarity to the semantics of P\ b P 2 ) and the set of paths 
B“(t) for i ^ 1 by B^t) = and S“+i(t) = \ [Ji=i Intuiti- 

vely, (t) is the set of paths starting in u and reaching a <? 2 “State within t time 
units in n steps, where the first n — 1 steps are ^-transitions and the last step is 
a i?-transition. denotes the subset of consisting of paths that reach 

a <? 2 -state in n steps without performing an A fl S-transition to a <? 2 -state in 
the previous steps. 

Note that Bf{t), B}‘{t) are pairwise disjoint (for i ^ j). By exploiting the 
fact that { cr € Pat/i(u) | a \= Pi aU^^ B'^ 2 } = Un^i obtain: 

00 

Pr{ cr G Pot/i(M) I a \= Pi aW^^ BP 2 } = Pr{ cr G B}{ (f) }. 

i=l 

Hence, it is sufficient to show that for arbitrary t > 0, 

00 00 

^Pr{aGi?rW} = Y.^r{aGB}{t)}. 
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We fix some t > 0, and prove the above by showing the stronger property that 
for all positive n, Pr{ cr £ } = Pr{ a £ This proof proceeds by 

induction on n, the length of the paths in and So, we perform a 

nested induction, the (inner) induction on n is nested in the (outer) induction 
on the structure of the formula <l>. 

In the base case n = 1 of the inner induction, let us first assume u ^ <Pi. But 
then V ^ <l>i (by the outer induction hypothesis) and hence Pr{ cr £ B“(t) } = 
0 = Pr{ cr £ Bi{t)}. If, conversely, m |= <?i, we obtain v \= hy the outer 
induction hypothesis, and therefore 



Here, C |= denotes that all states in the equivalence class C satisfy <^2, which 
we can assume by the outer induction hypothesis. The transformation labelled 
(+) uses that (u,v) £ R implies ^ci(w, w) = w), since C is 

the class of a Markovian bisimulation. 

To complete the inner induction we now assume that for arbitrary n > 1 we 
have that Pr{ a £ B^{t) } = Pr{ a £ B^{t) }, and aim to show that this also 
holds for n + 1. The case u ^ proceeds as above. The remaining case, u \= <l>i, 
leads to the following transformation, using the same arguments as above. 



Pr{a £ H(‘(t)} 





Pr{a e B^{t- x)} dx 

'.CeM\R, CMi 'LweC^A{u,w)- Pr{cr £ B^{t-x)} dx = 
- • — — - W -Ti Rij w)- Pr{a € B^{t — x)} dx = 

’{t — x)} dx = 










This completes the proof sketch, details can be found in [25]. 
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